PalmOS-like data storage

Derek Pressnall dpressnall at
Sat Jan 27 21:18:22 CET 2007

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
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?

More information about the openmoko-devel mailing list