STATUS UPDATE: Got mickey and dos1's agreement (they are the "leaders" of opimd). Will start (actually will help dos1) working on it asap. If you want to add anything, please add now.
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.
Changes in fields
UPDATE: What we decided to go with: (now implemented)
org.freesmartphone.PIM.Type.Add(name, type) <--- Adds the name and type
org.freesmartphone.PIM.Type.List() <---- returns the list of available fields, format name:type.
org.freesmartphone.PIM.Type.Delete(name) <-- returns nothing
org.freesmartphone.PIM.Type.Get(name) <--- returns the type of the field.
General for all of opimd:
org.freesmartphone.PIM.Types.List() <---- returns the list of available types in a tuple.
Types.List() returns the same thing for all the domains.
This is the complete API (in freesmartphone docs). There are a couple of default fields, those fields can be overwritten, but if no value exists for them, they are used (also listed in the docs)
How to use: You can just use opimd like you have used it until now. BUT if you want opimd to work with number resolving (or any other field handling) you should add a matching type. So let's say to add support for the "Cellphone" field, we'll just have to:
or for supporting "Nickname" we'll have to:
This will let opimd assume things about the values inside (for instance assume that phonenumber is important and should probably be an indexed property). But also will let you (and more importantly the UI apps) work in a sane number knowing the types (and let's say, adding icons per type).
The Types.List() is just for helping you know what's currently supported in opimd.
As I said, you can still use fields without types, but then the apps (and opimd) will not be able to search them correctly.
- Enable querying by type, i.e, query where "phonenumber" = 123 will search in all the fields that have the type phonenumber.
Changes in query method
NOTE: keep the old way, but also implement this:
I don't get why we use this querying method, it just makes everything weird hard to handle.
Furthermore, it'll be easier and faster to get only "phone number" fields for matching (in opimd), the user of the API will just be able to tell it "find me a phone_number field that matches this number" and will not force us to check each field like we do atm.
opimd should internally use sqlite for caching as it's faster, easier to handle and generally better.
It should really be possible to ask opimd for several contacts at once, i.e ask him for the contacts "Tom, dick and harry" or for the numbers "123, 435 and 546546" at one query, because querying opimd for 70 different contacts at one time (phonelog) is terribly slow.
Furthermore it should be able to ask for a "join" of backends when requesting from one. i.e, I want to be able to ask opimd for the messages and the corresponding contacts for each message in one query, or even ask opimd for all the messages that match all the numbers from the contact "Charley".
Query reply should be possible to sort differently depending on the national character encoding.