Re: [Evolution-hackers] Thinking about e-d-s for handhelds

[JP Rosevear <jpr novell com>]

On Wed, 2005-03-30 at 15:43 +0100, Ross Burton wrote:
> Hi,
> 
> I've been thinking recently about using evolution-data-server in the
> handheld linux environment.  It has a lot going for it:
> 
> * handles email, contacts, calendar, to do
> * plugable backends
> * fairly sane client API
> * a number of client applications already exist
> 
> However, the number of dependencies are quite high: libgnomeui, bonobo,
> soup, etc.  Also a number of backends are not required on handhelds to
> start with, so can be removed.  I thought I'd run my ideas past everyone
> now before I start, to get feedback on what can and can not be accepted
> upstream.

I don't think soup is all that high, it just depends on glib.

> * libgnomeui removal
> 
> Now that my patches removing the basic libgnomeui use is in, there are
> only two instances of libgnomeui code in EDS.  One is to get the
> "application crashed" dialog, which I shall patch out (as its a one-line
> change).  The other is a widget in libedataserverui (GnomeFileEntry),
> which has been deprecated and has a replacement in GTK+ 2.6.  As the
> target system uses GTK+ 2.6, I shall port the code to this new widget.

We would take the latter for 2.3/2.4.  For the former, without this its
harder for the average user to report dialogs, but we could probably
accept a --disable-crash-dialog configure switch.

> * Backend selection
> 
> I plan on adding options to configure to turn off various backends, so
> that I could (for example) turn off the groupwise and webcal backends to
> remove the soup dependency.

Well, these are all loadable modules now so it shouldn't be too hard to
create a configure switch around this, but as above, I don't see libsoup
being terribly high in the stack - especially useful on handhelds for
webcals.

> * Removing Camel usage from libebook
> 
> If I decided that I wanted to just use the contacts and calendar portion
> of e-d-s, Camel still has to be built as libebook uses
> CamelInternetAddress.  I plan on working out a way of removing the
> dependency of camel on libebook.

Well, I'd hate to see internet address parsing get into the state that
url parsing is (there are atleast 3 url parsers in use).

> * Memory use analysis
> 
> Investigation into various backends to find out how memory much memory
> is being allocated, and if it can be improved to reduce memory usage.

Always willing to take anything sensible in this field.

> * DBus port
> 
> This is the big task.  The current target system doesn't use CORBA for
> IPC, but DBus.  I would attempt to port the backend CORBA code to DBus.

Well, I'd be interested to see how this goes, but I wouldn't want to see
this in the 2.3/2.4 code base.

-JP
-- 
JP Rosevear <jpr novell com>
Novell, Inc.