PalmOS-like data storage

Knight Walker moko at
Tue Jan 30 19:17:27 CET 2007

On Tue, Jan 30, 2007 at 09:07:16AM -0500, Gervais Mulongoy wrote:
> Maybe someone can point me to some documentation regarding all this. It is a
> very interesting topic and I don't even know where to start looking so I can
> properly follow the thread.

Don't really know if there's any documentation on this, but as an "experienced"
UNIX admin and user, I think I can chime in here.

> My concerns:
> First, what is the current way of doing this with the Unix? What problems
> does this have?

The "current way" is that each application has completely free reign on how it
stores data.  Some programs use flat (text) files, some use GConf, some use
databases (embedded ones like BerkleyDB or SQLite, or external ones like MySQL,
PostgreSQL, etc).  The problem this has is that everyone uses their own methods
for storing data.  Not exactly conducive for a small system like the MoKo.

> Second how does gconf do (in terms of data storage), and how does it go
> about attempting to solve the problems with the Unix way. And the same
> questions for how KDE/sqlite/etc do things

GConf (From what I've seen) tries to combine the two major schools of thought
regarding storage of configuration options: human readability and machine
manipulation (i.e. options easily changed from within the program).  GConf
uses a hierarchy to store settings (Like Windows' Registry), but it doesn't
stick this in a binary file format; it uses XML files in a directory
structure to try and organize things.

I can't speak for KDE though, as I don't use it.  SQLite (being an
embedded database) accesses data in the widely-understood relational data
model. However it uses a single file for each database by default, making
twiddling options from the command line (by editing or even removing files)
more difficult.  But it's great if you need to keep track of a few thousand
pieces of information and understand SQL.

> This will at least give us a list of requirements for data storage needs of
> the OpenMoko as a platform. Which we can use to either roll our own
> storage/vfs/whatever, or to bring an existing project up to par with what
> the community thinks we need.

Well, there are several ways to solve the data storage needs of OpenMoKo,
however, as so many people now have experience with relational databases, I'd
be willing to bet that SQLite (Or something based on it) gets the nod. The
reason I feel this way, without having seen any of the code, is thatSQLite is
lightweight (Under 400k on my workstation, and could probably be made smaller
on the MoKo) and it doesn't suffer from some of the same limitations that
older embedded database formats like BerkleyDB do.  Plus (No flames on this,
please) SQLite is Public Domain while BerkleyDB is GPL (By default) which
means SQLite can be used for free in proprietary programs, while the
developer has to pay for that privilege with BerkleyDB.


More information about the openmoko-devel mailing list