>>> 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. _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
