Making use of calendar

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