mail and contacts app

Jon Phillips jon at rejon.org
Sat Feb 3 23:46:42 CET 2007


On Sat, 2007-02-03 at 12:01 +0100, Philip Van Hoof wrote: 
> 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.

Oh, that is small :)

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

So this possibility is completely dead?

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

Also, could you elaborate on how tinymail could support SMS text
messaging and other phone message types. How could this be done? What
are your thoughts on this?

Jon

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