On Mon, 2008-07-07 at 19:29 +0200, Sören Apel wrote: > -) EDS is inflexible. > If it were flexible enough, things like libmokojournal would not have > been needed to be written: > http://svn.openmoko.org/trunk/src/target/OM-2007.2/libraries/libmokojournal2/
libmokojournal2 is a convenience library around libecal. Sounds like a reasonable thing to do, unless you think that logging calls and text messages is a core component in a PIM solution. > -) EDS has limits. > http://www.gnome.org/projects/evolution/developer-doc/libebook/EContact.html#EContactField > Fixed set of fields. Want to add a field not in the enum? Tough luck. Incorrect. EContact has a fixed field API because it provides convenience wrappers -- when you fetch an address field you don't get a single string composed of semicolon separated fields, but a EContactAddress struct with named members. EVCard, the parent class of EContact, doesn't assume any field naming. > Fixed number of pre-defined fields. Want to add a fifth eMail-address? > Tough luck. Incorrect. EContact has convenience fields to get the first, second, and so on email address. Don't use those, use E_CONTACT_EMAIL and you'll get a GList of all email addresses. The alternative again is to use EVCard, it doesn't provide magic accessors but doesn't have any limits. > Want to have two contacts refer to the same address? No go. That is true -- there is no standard way of sharing address information. You could add a X-REF parameter to the ADR element and use that to point to another contact with the relevant address information in. > Want to have two contacts cross-reference each other as they're spouses? Add a X-SPOUSE field and define its value to be the UID of the spouse, instead of a free-form string. Alternatively, use a REF parameter to specify the UID of the spouse contact. > No go. > The list goes on. I look forward to more feedback. It appears that people look at EContact believing that it is an accurate representation of the EDS addressbook functionality, but as anyone who has touched a vCard knows its actually a fixed and simple wrapper for people who don't want to touch the details of how vcards work. A vCard is a list of fields. Fields have a list of parameters, and a list of values. The vCard specification defines field names (FN, ADR, NICKNAME, etc) but you can add arbitrary fields by prefixing the name with X-. You can also add arbitrary parameters to fields. > > Maybe someone can give me a hint what the benefit of pyPimd would be > > over plain EDS? (Embedded EDS) > > D-Bus alone does not sound like a selling point for me. > > Correct. D-Bus alone isn't the selling point. Flexibility, scalability > and improved abstraction are. Also, we think that clients should build > on an API that's fun to use, doesn't get in their way and does what they > want. > Don't get me wrong - EDS is nice and is good at what it does. But we > need to move on and improve on it because it isn't and shouldn't be the > be-all end-all. We can't find better ways of doing things unless we try. > And that's what I'm doing :) Anyone who has spoken to me about this knows that I'm the first person to say that EDS needs a good rewrite, and I've been making vague motions towards a complete reimplementation from scratch. I have good reasons though, and "EDS isn't flexible enough" when it is as flexible as you could wish isn't really a great argument. But hey, I've had this discussion so many times now it's getting quite boring. I'll watch pypimd with interest, just as I'm watching People. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF