Opimd redesign

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Changes in fields)
Line 30: Line 30:
  
 
This will make everything easier for the users of the API to handle and will be sane!
 
This will make everything easier for the users of the API to handle and will be sane!
 +
 +
 +
'''Explanation of exactly what I meant (TAsn)'''
 +
 +
/org/freesmartphone/PIM/Contacts
 +
 +
org.freesmartphone.PIM.Fields.Add(name, type) <--- Adds the name and type
 +
 +
org.freesmartphone.PIM.Fields.List(name) <---- returns the list of available fields, format name:type.
 +
 +
org.freesmartphone.PIM.Fields.Delete(name) <-- return nothing
 +
 +
org.freesmartphone.PIM.Fields.GroupGet(name) <--- returns type
 +
 +
 +
 +
name is string, type is string as well.
 +
 +
Name has to be unique (i.e no two fields with the same name in the same domain)
 +
 +
type is one of the types known to opimd (will be explained in a moment)
 +
 +
 +
 +
This is the part I'm unsure of:
 +
 +
/org/freesmartphone/PIM/FieldTypes (or something like that)
 +
 +
org.freesmartphone.PIM.Types.Add(name, type) <--- Adds the name and type
 +
 +
org.freesmartphone.PIM.Types.List(name) <---- returns the list of available fields, format name:type.
 +
 +
org.freesmartphone.PIM.Types.Delete(name) <-- return nothing
 +
 +
org.freesmartphone.PIM.Types.Get(name) <--- returns type
 +
 +
 +
 +
I want anyone to be able to add future types (to search by) with no special opimd handling, i.e I want to be able to add IRC although you don't know how to handle it, name of the type will be irc, type of the type will be text(limited to X chars, he should state that when making the type, or maybe unlimited if he wants) or he can also set the type to "numeric", "int" etc etc.
 +
 +
This way he'll bind a type, called "IRC" that can contain text values only, this means that if he'll want to add a field called "Main-nick" he'll be able to set the type to "irc" (the one that we set earlier) that'll let him search in all the irc nicks easily and will also let opimd know what to expect in this type. (string limited to 300 chars for instance).
 +
 +
 +
 +
Continuing with the IRC example I'll be able to add to the conact tom the following fields:
 +
 +
Main-nick : "TAsn"
 +
 +
Alt-nick  : "TAsnn"
 +
 +
 +
 +
Though I won't be able to do that before I add the type (like this:
 +
 +
org.freesmartphone.PIM.Fields.Add("Alt-nick", "IRC")
 +
 +
And I won't be able to do that before I do:
 +
 +
org.freesmartphone.PIM.Types.Add("IRC", "text") (phonenumber/text/date/etc will be predefined by opimd, maybe even add a method to expose what's available there, but that can not be changed by API the "text" and etc types are set by opimd and opimd only)
 +
 +
 +
 +
This lets the APPS to easily set types for fields and for opimd to easily know where to search (When looking for IRC), what to expect when searching (a text field, not a number that's needed to be normalized, etc).
 +
 +
So, in our example in order to know who of the contacts posses the nick "TAsn" we'll just need to search all of the fields with the type IRC (user of the API will know to ask it). That's about it, I think.
 +
 +
I hope it's clean enough, let me know.
  
 
= Changes in query method =
 
= Changes in query method =

Revision as of 22:30, 2 December 2009

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.

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!


Explanation of exactly what I meant (TAsn)

/org/freesmartphone/PIM/Contacts

org.freesmartphone.PIM.Fields.Add(name, type) <--- Adds the name and type

org.freesmartphone.PIM.Fields.List(name) <---- returns the list of available fields, format name:type.

org.freesmartphone.PIM.Fields.Delete(name) <-- return nothing

org.freesmartphone.PIM.Fields.GroupGet(name) <--- returns type


name is string, type is string as well.

Name has to be unique (i.e no two fields with the same name in the same domain)

type is one of the types known to opimd (will be explained in a moment)


This is the part I'm unsure of:

/org/freesmartphone/PIM/FieldTypes (or something like that)

org.freesmartphone.PIM.Types.Add(name, type) <--- Adds the name and type

org.freesmartphone.PIM.Types.List(name) <---- returns the list of available fields, format name:type.

org.freesmartphone.PIM.Types.Delete(name) <-- return nothing

org.freesmartphone.PIM.Types.Get(name) <--- returns type


I want anyone to be able to add future types (to search by) with no special opimd handling, i.e I want to be able to add IRC although you don't know how to handle it, name of the type will be irc, type of the type will be text(limited to X chars, he should state that when making the type, or maybe unlimited if he wants) or he can also set the type to "numeric", "int" etc etc.

This way he'll bind a type, called "IRC" that can contain text values only, this means that if he'll want to add a field called "Main-nick" he'll be able to set the type to "irc" (the one that we set earlier) that'll let him search in all the irc nicks easily and will also let opimd know what to expect in this type. (string limited to 300 chars for instance).


Continuing with the IRC example I'll be able to add to the conact tom the following fields:

Main-nick : "TAsn"

Alt-nick  : "TAsnn"


Though I won't be able to do that before I add the type (like this:

org.freesmartphone.PIM.Fields.Add("Alt-nick", "IRC")

And I won't be able to do that before I do:

org.freesmartphone.PIM.Types.Add("IRC", "text") (phonenumber/text/date/etc will be predefined by opimd, maybe even add a method to expose what's available there, but that can not be changed by API the "text" and etc types are set by opimd and opimd only)


This lets the APPS to easily set types for fields and for opimd to easily know where to search (When looking for IRC), what to expect when searching (a text field, not a number that's needed to be normalized, etc).

So, in our example in order to know who of the contacts posses the nick "TAsn" we'll just need to search all of the fields with the type IRC (user of the API will know to ask it). That's about it, I think.

I hope it's clean enough, let me know.

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.

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

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

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

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.

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.