Opimd redesign

From Openmoko

(Difference between revisions)
Jump to: navigation, search
Line 31: Line 31:
 
= Changes in query method =
 
= Changes in query method =
 
I don't get why we use this querying method, it jsut makes everything weird hard to handle.
 
I don't get why we use this querying method, it jsut makes everything weird hard to handle.
 +
 +
 +
= Internal design =
 +
opimd should internally use sqlite for caching as it's faster, easier to handle and generally better.
  
 
[[Category:FSO]]
 
[[Category:FSO]]
 
[[Category:Middleware]]
 
[[Category:Middleware]]
 
[[Category:PIM]]
 
[[Category:PIM]]

Revision as of 21:03, 14 October 2009

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.


Internal design

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

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.


Internal design

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