mail and contacts app

Philip Van Hoof spam at pvanhoof.be
Sat Feb 3 12:01:34 CET 2007


On Fri, 2007-02-02 at 14:27 -0800, Jon Phillips wrote:
> On Fri, 2007-02-02 at 23:21 +0100, Koen Kooi wrote:
>  
> > Jon Phillips schreef:
> > > In the other openmoko, Philip Van Hoof, creator of tinymail
> > > (www.tinymail.org) brought up how it would be a good mail app for
> > > openmoko. I agree.
> > > 
> > > I also think that consolidating behind the simple contact app,
> > > http://projects.o-hand.com/contacts would be a good idea.
> > > 
> > > Both use Evolution Data Server and are aimed at OpenMoko/OLPC/handheld
> > > devices.
> > 
> > Right, there's one snag: tinymail uses its own forked little version of EDS, so if you use
> > tinymail + openmoko PIM, you will have *2* copies of the EDS libs on your device :(
> > 
> > regards,
> > 
> > Koen
> 
> Oh, that is not good!  Philip how can this be dealt with? Is this true
> and if so, how could your changes be merged back into mainline EDS?


Tinymail does not use its own forked version of "EDS" but of one little
component of it, named Camel, that isn't integrated with the rest of
"EDS" in "any" technical way whatsoever.

The only reason why "Camel" is still in "EDS" is for political reasons.

The Camel in tinymail has also been renamed to "camel-lite" for avoiding
clashing the library names. The locations of the include files and the
shared object files have "-lite" appended to the target directories for
that same reason (in case you would want to install tinymail in the same
prefix as evolution-data-server, it still wouldn't clash).

The entire Camel API is still available (and should be even binary
compatible).

The implementation, however, has been significantly changed. Tinymail
can't work with a non such modified version of Camel. In other words: it
*needs* the modifications.

Tinymail therefore doesn't link with "EDS" but embeds the build of this
camel-lite and everything is dealt with automatically (so in reality,
nobody needs to worry about it).

The binaries of camel-lite have also been significantly reduced in size
and some parts of it are being compiled statically rather than
dynamically. The very very small parts that where once shared with some
common libraries of other "EDS" components are, for example, statically
linked into tinymail's camel-lite. This amounts to ~ 2 or 3 kb of binary
compiled data.


pvanhoof at lort:~$ ls /opt/tinymail/lib/pkgconfig/camel-lite-*
/opt/tinymail/lib/pkgconfig/camel-lite-1.2.pc
/opt/tinymail/lib/pkgconfig/camel-lite-provider-1.2.pc
pvanhoof at lort:~$ 

pvanhoof at lort:~$ ls /opt/tinymail/include/camel-lite/
camel
pvanhoof at lort:~$ 

pvanhoof at lort:~$ ls /opt/tinymail/lib/libcamel-lite-*so*.0
/opt/tinymail/lib/libcamel-lite-1.2.so.0
/opt/tinymail/lib/libcamel-lite-1.2.so.0.0.0
/opt/tinymail/lib/libcamel-lite-provider-1.2.so.8.1.0
pvanhoof at lort:~$


So, basically, the only thing that changes for people who have been
building something using the Camel API, is this in their configure.ac:

- PKG_CHECK_MODULES(CAMEL, camel camel-provider)
+ PKG_CHECK_MODULES(TNYCML, camel-lite camel-lite-provider)


So saying that you will have two copies of the "EDS" libs on the device,
is a little bit overreacted. It's only one component of it.

A component that is not being used by any of the current users of
eds-dbus.


Other than that could camel-lite have been integrated with eds-dbus. The
maintainers of eds-dbus where not interested in the changes, sadly. I
tried though.

On the other hand does tinymail *need* the changes. Tinymail will not
work without the changes and tinymail wouldn't be tinymail if not with
the changes. The libtinymail-camel also uses a lot of the new API that
have been introduced by the changes.

But it's all *new* API. Keeping the old API functional.


-- 
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