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 <[EMAIL PROTECTED]> Novell, Inc. _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
