Push Email

Jon Phillips jon at rejon.org
Wed Feb 7 19:26:27 CET 2007



On Wed, 2007-02-07 at 10:30 +0100, Philip Van Hoof wrote:
> Yes, The thing is that as the tinymail developer, I can't really
> anticipate on things like this until they get decided and are known to
> me.
> 
> Well, that's not really true. I can, and have, anticipated 'the unknown'
> in the design of tinymail. I frequently tell people "Change is among
> us", well this again proves it definitely *IS*.
> 
> I anticipated in that the design flexible on how you implement the
> observable's part of the game. That can be SyncML but, as you now can
> see, also IMAP IDLE on the same thread and using the same connection as
> your normal IMAP one.
> 
> Who knows tomorrow we will all get mail notification through some
> obscure bits in the TCP/IP headers of the GPRS connection? And who knows
> will we someday have to look at the VPI + VCI of ATM cells to know from
> which provider the messages came? Whether or not it's possible, ATM
> isn't used for phones, or whether it's a good solution is not really the
> point.
> 
> Well, not for tinymail. That's an implementation detail for tinymail.
> 
> The design that will cope with the event, which is the well known
> observer pattern, will deal with it once the observable is implemented.
> 
> If you need a "Click" kernel module for that, to feed certain bits to
> the application layer, then that's great.
> 
> I hope to make that message very clear in clarity ;). The IMAP IDLE
> support is not a demo, no, but it's also not a statement: I'm not
> sticking to 'just' IMAP IDLE. Tinymail could and 'will' cope with other
> Push E-Mail notification methods. It's designed to do so. And it will.
> 
> So ... basically .. ( and forgive me for my direct & to the point style
> of discussion. I don't mean anything anti-empathic with it :-p ) :
> 
> Please develop me the method for notifying your phones about messages
> over the networks that will be used, give me the technical details, and
> let's implement a libtinymail-openmoko platform specific library that
> deals with this. Does that sound good? 
> 
> 3..2..1 Go! :-)


Philip, this rapid implementation is excellent. Could an official
openmoko dev. enlighten this situation a bit more :) Mickey?

Thanks!

Jon

<snip />

-- 
Jon Phillips

San Francisco, CA
USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon at gristle.org
IRC: rejon at irc.freenode.net





More information about the openmoko-devel mailing list