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 _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community