PalmOS-like data storage

[Gervais Mulongoy]

Thanks for the information.

Here's what I found regarding SQLite which could potentially solve the issue
with "twiddling" options from commandline. http://www.nongnu.org/libsqlfs/.
It seems that SQLite can be used as a back-end for a userspace filesystem
(FUSE).

On 1/30/07, Knight Walker <moko at kobran.org> wrote:
>
> 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.
>
> -KW
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20070201/6d7514f4/attachment.html