mail and contacts app

Jon Phillips jon at rejon.org
Sun Feb 4 20:24:31 CET 2007


On Sun, 2007-02-04 at 13:16 +0100, Philip Van Hoof wrote:
> On Fri, 2007-02-02 at 16:30 -0800, Jon Phillips wrote:
> > On Fri, 2007-02-02 at 17:21 -0700, Richi Plana wrote:
>  
> > > The thread started here:
> > > http://lists.openmoko.org/pipermail/openmoko-devel/2007-January/000073.html
> > > 
> > > Does that make it three versions of EDS we're talking about (the Novell
> > > original, Philip van Hoof's and EEDS)? Or is Phillip's and EEDS the
> > > same?
> > 
> > No, actually, that is the version that these systems use. So, if that is
> > the case, then we have one unified one :)
> > 
> 
> Tinymail does not really use any of the 'other' components of eds. The
> only component that it uses, in a very modified form, is the camel
> component.
> 
> Although camel is part of eds, it's not really integrated or used by the
> other eds components. In fact it's surprisingly disconnected from any
> other such eds component (and could have been done as a separate library
> too).
> 
> The tinymail project took that LGPL component ... made a series of
> changes to it. These changes are slowly going to become available in the
> upstream version. And even more slowly into the eds-dbus version (as the
> maintainers of eds-dbus told me that they are planning to "in phases"
> bring "upstream"-only to eds-dbus. Not to mix multiple versions of
> multiple components into their distribution).
> 
> The problem with this is that the camel changes that I did for tinymail
> are very much targeted at mobile devices. Upstream Evolution is very
> unlikely to accept all of them. So some of them will never reach
> upstream.
> 
> Therefore wont they reach eds-dbus either (as the eds-dbus team is only
> interested in the upstream eds). 
> 
> The funny part is indeed that both eds-dbus and the camel of tinymail
> are targeted at mobile users. But it's the redirection that the camel of
> tinymail has to take, that is going to make it nearly impossible to get
> all changes into eds-dbus.
> 
> The exact same style of changes have happened to eds-dbus. But those
> changes of course didn't have to take that route.

Do these changes seem to speed up your app and possibly could speed up
Evolution in general? I'm having great fun with these apps because of
their speed (almost to the point of where I want to use them full-time
rather than "crashy" evolution!!!)

> Note that I *did* actively contact them about this and that I *did* tell
> them that we should better cooperate and work on a single version. They
> *did*, however, told me that they are only interested in "upstream" eds.

Is EDS mostly controlled by Novell? Yes, seems like a big wall to jump
to get changes in...like OO.o or something...

> Which is perfectly understandable (so I said it, don't get angry with me
> dear eds-dbus team: I "do" understand) and fine for me. 
> 
>  ..... And which is why tinymail is using its own internally build Camel
> and not the one in eds-dbus, indeed. I really like to get things done,
> you know.

That is cool and good to know (even though you are prolly sick of having
to repeat this all the time ;)

> 
> Now,
> 
> I didn't make these changes for zero reasons. In fact does tinymail need
> all of the changes that have happened. That's because I have been very
> conservative in making changes to the camel. So only if really really
> needed, did I make them. So all changes naturally are really needed.
> 
> A list of the changes:
> 
>   o. Offline POP3 support
>   o. Summary support for POP3 using TOP
>   o. CONDSTORE support
>   o. BINARY support
>   o. Bandwidth reductions when retrieving the summary from IMAP
>   o. Really major memory consumption reductions when dealing with
>      summaries
>   o. Extremely major memory consumption reductions when downloading
>      summary from IMAP servers
>   o. A major memory consumption reduction when downloading a message
>      from an IMAP server (streaming it directly from the TCP/IP stream
>      to the filesystem, rather than first copying it)
>   o. Support for partial retrieval (only the message, not the
>      attachments) for IMAP
>   o. Support for partial retrieval (only the message, not the
>      attachments) for POP
>   o. Multiple bugfixes (major ones)
>   o. Removing all compilation warnings and also some real bugs caused by
>      not looking at them (using variables uninitialised, which happened
>      quite often in Camel)
> 
> In *near* future will much more such changes happen. For example IDLE
> support in the IMAP provider of Camel and changes to all the subsystems
> of Camel that are needed in order to support this.

Man, I want to run with these changes when using Evolution...this is
great!

Jon

> 
> -- 
> Philip Van Hoof, software developer
> home: me at pvanhoof dot be 
> gnome: pvanhoof at gnome dot org 
> http://www.pvanhoof.be/blog
> 
> 
> 
> 
> 
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/community
-- 
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