View source for Opimd redesign
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Opimd redesign.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Opimd redesign.
This page will gather all the suggestions (and will be a decent design sketch) for the redesign of opimd. After many discussions in IRC we decided opimd needs a redesign.
Main topics that came up are: switching opimd to use sqlite for internal operations and adding configuration for types instead of the use of URIs. Many of the ideas that came up concerning the second idea are represented in this IRC log: http://pastebin.com/mb7fbf10 and in the logs from #openmoko-cdevel@Freenode on 09-10 of october 2009.
Furthermore, it has been suggested than a change in the sqlite backend db design is also needed.
Info about those changes will be shown here as soon as we'll have time to write it down.
ATM opimd just lets you add fields as you wish, this is bad, since you can't really categorize fields and have to use weird hacks like the "tel:" prefix.
I'm suggesting a move to a configuration you'll have the following dbus methods:
each field will have a type (phone number would be a type for instance) that will guide opimd on how to compare items of this type, again, in the case of phone numbers, use normalization.
The user of the API will be able to add fields and their types whenever he wants (and also remove such) and that will let us control opimd in a sane manner.
I think we also need a couple of default fields of special types:
This will make everything easier for the users of the API to handle and will be sane!
I don't get why we use this querying method, it jsut makes everything weird hard to handle.