Opimd redesign

From Openmoko

Revision as of 20:09, 28 October 2009 by Vanous (Talk | contribs)

Jump to: navigation, search

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.

Contents

Changes in fields

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:

  • ListFields
  • AddFiled
  • DelField
  • GetField

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:

  • Phone - returns the default phone (of all the cells with type phone)
  • Name - returns "First Last, nick" or something like that.
  • SIP - returns default contact info for sip
  • SMS - returns default phone number for SMS etc etc.

This will make everything easier for the users of the API to handle and will be sane!

Changes in query method

I don't get why we use this querying method, it jsut 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.

Internal design

opimd should internally use sqlite for caching as it's faster, easier to handle and generally better.

Query improvements

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.

Personal tools

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

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:

  • ListFields
  • AddFiled
  • DelField
  • GetField

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:

  • Phone - returns the default phone (of all the cells with type phone)
  • Name - returns "First Last, nick" or something like that.
  • SIP - returns default contact info for sip
  • SMS - returns default phone number for SMS etc etc.

This will make everything easier for the users of the API to handle and will be sane!

Changes in query method

I don't get why we use this querying method, it jsut 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.

Internal design

opimd should internally use sqlite for caching as it's faster, easier to handle and generally better.

Query improvements

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.