Plea to developers: Make data for all applications available to scripting languages

[Kero van Gelder]

>>> What I would like to see is ALL programs having a way of getting at their
>>> data from a scripting language. I don't know if it makes sense to have 
>>> some
>>> guidelines for developers to make it easier for this information to be 
>>> got
>>> at. This would be for someone more competent than me to suggest.
>>
>> Quite simply, if long term storage utilises and embedded database then so 
>> long as the scripting language can access it then it will be fine.
> Only if the database supports concurrent access by multiple processes, 
> which most don't.  You'd be better off supporting a single standard API to 
> obtain the obvious data such as contacts/calendar/todos (EDS being the one 
> that I believe that the developers have settled on).
>
> Which leads to a question: is there some way to extend the information held 
> for each EDS entity so that calendar entries contacts and the like can have 
> additional (arbitrary) fields?

Underneath eds, there's VCARD, rfc 2426, http://www.ietf.org/rfc/rfc2426.txt
It's an ancient-looking format that everybody is using. As messy as it it,
I have little doubt that OpenMoko will keep using it.

In various places, the TYPE can handle only a few values. So for instance,
a person can have a Delivery Address for home, work, but none other.
a non-delivery address does not exist, as far as I can see (so I bet ADR,
the delivery address, gets abused a lot). A limit of two addresses for
a contacts is... so low, I have a feeling I must be missing something.
Evolution has an 'other' address, for instance, but I can not find that
in the RFC.

You can specify X-OPENMOKO-SOMETHING lines, which I guess would work, i.e.
we can have our local openmoko app show the values, but
will be ignored by Evolution (i.e. not shown, yet retained) if you transfer
your data. I am tempted to dump my own data in lines like that, until I
find a better solution. There's a whole series of X-EVOLUTION-* lines in
vcards exported by evolution, too.

The related calender format is iCal, rfc 2445.

Bye,
Kero.