mail and contacts app

Philip Van Hoof spam at pvanhoof.be
Sun Feb 4 13:16:18 CET 2007


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.

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.

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.


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.


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog








More information about the openmoko-devel mailing list