PalmOS-like data storage
gervais.mulongoy at gmail.com
Thu Feb 1 17:45:15 CET 2007
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
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
> > properly follow the thread.
> Don't really know if there's any documentation on this, but as an
> 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
> > 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
> databases (embedded ones like BerkleyDB or SQLite, or external ones like
> PostgreSQL, etc). The problem this has is that everyone uses their own
> 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
> 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
> 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
> more difficult. But it's great if you need to keep track of a few
> pieces of information and understand SQL.
> > This will at least give us a list of requirements for data storage needs
> > 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
> > 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,
> 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
> lightweight (Under 400k on my workstation, and could probably be made
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openmoko-devel