PalmOS-like data storage

Milan Votava votava at mageo.cz
Sat Jan 27 21:39:43 CET 2007


At 21:18 27.1.2007, Derek Pressnall wrote:
>Milan Votava wrote:
>>It would be nice to have something like the ODM database from AIX OS
>>where all configuration records can be stored.
>
>I've had something brewing in the back of my head for a while that was
>along these same lines.  However, everytime I mention it to someone,
>what usually comes back is "you mean like the Windows registry?",
>which of course has very bad karma.  Also, the ODM on AIX has been
>known to get corrupted before, and it is hard to recover from (being a
>binary format).
>
>My idea was to have something very similar, but without the "binary
>data file" backend that plauges windows registry and odm.  The front
>end would be a C api (with command line equivilant for shell scripts)
>where you can register and store objects in a tree structure.  A
>particular tree root would be an object type, that has a backend file
>format for that object.  Any object node / leaf could be a reference
>to another tree root.  Support tree file formats would include binary
>(sqlite), stanza-based text files (like the ones in AIX config files,
>or .ini files), or colon delimited files for things like /etc/passwd.
>But everything would be accessible as objects using the same front-end
>api, and various trees could be linked via other trees.  For example,
>the path:
>  system->users[uname = bob]->preferences->app[dialer]->ringvolume
>would look at the "system" object, which has a "users" object
>implimented via a /etc/passwd file as it's data file.  It looks up the
>user name "bob", and the "preferences" object resolves by looking at
>his home directory and pulling up a stanza-based file in there that
>has a stanza for each app.  One app, "dialer", is a stanza that has
>property value that pulls up the tree of preferences for the dialer
>app.
>Now various points along this path link to another data file of a
>possibly differnt format.  So if something goes bad with the dialer
>app, it is only going to corrupt it's own preferences.
>Hopefully all this could be put in place with a minimum amount of
>code, and if it is modular enough then additional file formats can be
>added on the fly.  But is this to complicated for a phone?

I absolutely agree with your post. The only change I suggest is to replace:

system->users[uname = bob]->preferences->app[dialer]->ringvolume

by:

system->users[uname = 
bob]->preferences->profile[night]->app[dialer]->ringvolume

(or maybe
system->users[uname = 
bob]->preferences->app[dialer]->profile[night]->ringvolume
)


As a developer of one of a few profile managers (profiles) for Palm 
OS Treos I suggest following:

1/ to take profiles seriously. It's a must on a smartphone
2/ to create a unified profile manager support/API. In fact it's 
impossible to create a fully profile driven environment on Treo just 
because of lack of this API. Every of 20000+ apps for Treo has its 
own way how to store related configuration data and there is no way 
how to change this now after so many apps have been created without a 
profile manager in mind...

Milan  





More information about the openmoko-devel mailing list