Thanks for the information.<br><br>Here's what I found regarding SQLite which could potentially solve the issue with "twiddling" options from commandline. <a href="http://www.nongnu.org/libsqlfs/">http://www.nongnu.org/libsqlfs/
</a>. It seems that SQLite can be used as a back-end for a userspace filesystem (FUSE).<br><br><div><span class="gmail_quote">On 1/30/07, <b class="gmail_sendername">Knight Walker</b> <<a href="mailto:moko@kobran.org">
moko@kobran.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Tue, Jan 30, 2007 at 09:07:16AM -0500, Gervais Mulongoy wrote:
<br>> Maybe someone can point me to some documentation regarding all this. It is a<br>> very interesting topic and I don't even know where to start looking so I can<br>> properly follow the thread.<br><br>Don't really know if there's any documentation on this, but as an "experienced"
<br>UNIX admin and user, I think I can chime in here.<br><br>> My concerns:<br>> First, what is the current way of doing this with the Unix? What problems<br>> does this have?<br><br>The "current way" is that each application has completely free reign on how it
<br>stores data. Some programs use flat (text) files, some use GConf, some use<br>databases (embedded ones like BerkleyDB or SQLite, or external ones like MySQL,<br>PostgreSQL, etc). The problem this has is that everyone uses their own methods
<br>for storing data. Not exactly conducive for a small system like the MoKo.<br><br>> Second how does gconf do (in terms of data storage), and how does it go<br>> about attempting to solve the problems with the Unix way. And the same
<br>> questions for how KDE/sqlite/etc do things<br><br>GConf (From what I've seen) tries to combine the two major schools of thought<br>regarding storage of configuration options: human readability and machine<br>
manipulation (i.e. options easily changed from within the program). GConf<br>uses a hierarchy to store settings (Like Windows' Registry), but it doesn't<br>stick this in a binary file format; it uses XML files in a directory
<br>structure to try and organize things.<br><br>I can't speak for KDE though, as I don't use it. SQLite (being an<br>embedded database) accesses data in the widely-understood relational data<br>model. However it uses a single file for each database by default, making
<br>twiddling options from the command line (by editing or even removing files)<br>more difficult. But it's great if you need to keep track of a few thousand<br>pieces of information and understand SQL.<br><br>> This will at least give us a list of requirements for data storage needs of
<br>> the OpenMoko as a platform. Which we can use to either roll our own<br>> storage/vfs/whatever, or to bring an existing project up to par with what<br>> the community thinks we need.<br><br>Well, there are several ways to solve the data storage needs of OpenMoKo,
<br>however, as so many people now have experience with relational databases, I'd<br>be willing to bet that SQLite (Or something based on it) gets the nod. The<br>reason I feel this way, without having seen any of the code, is thatSQLite is
<br>lightweight (Under 400k on my workstation, and could probably be made smaller<br>on the MoKo) and it doesn't suffer from some of the same limitations that<br>older embedded database formats like BerkleyDB do. Plus (No flames on this,
<br>please) SQLite is Public Domain while BerkleyDB is GPL (By default) which<br>means SQLite can be used for free in proprietary programs, while the<br>developer has to pay for that privilege with BerkleyDB.<br><br>-KW<br>
</blockquote></div><br>