Plea to developers: Make data for all applications available to scripting languages
Kero van Gelder
kero at chello.nl
Sun Sep 16 13:42:57 CEST 2007
>>> 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.
More information about the community
mailing list