Making use of calendar

Ross Burton ross at burtonini.com
Sun Jul 13 14:52:47 CEST 2008


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: ross at burtonini.com
                                          jabber: ross at burtonini.com
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF







More information about the openmoko-devel mailing list