<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/19/2010 12:23 PM, Robert Kaiser wrote:<br>
<blockquote cite="mid:4C44A64E.7060308@KaiRo.at" type="cite">Anything
that can't be recreated from other data we have stored. If we
start doing that, we break the assumption that was laid on gloda
until this day, esp. if it means that other things than search
stop working with gloda disabled. And I'm not a friend of that, as
IMHO that would mean us basically creating another equivalent of
the Outlook .pst format, which is the largest failure in any
messaging app I ever saw and one of the worst data formats I ever
have heard of as it doesn't allow separation of data belonging to
different things.
<br>
</blockquote>
<br>
I think you may be making some assumptions about the implementation
and design decisions that are not consistent with my plans. It's
also worth noting that even if we were to store all authoritative
data exclusively in SQLite with no export support, the SQLite
database format is well documented (
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://www.sqlite.org/fileformat.html">http://www.sqlite.org/fileformat.html</a>
), the source is in the public domain and it compiles on basically
every platform available. We would have to go really far out of our
way to create an equivalent of the pst situation back in the day.<br>
<br>
My primary concerns about storing authoritative data are avoiding
data corruption and standardized export.<br>
<br>
SQLite does everything in its power to avoid data corruption. The
unfortunate reality of the situation is that not all file systems
and storage hardware actually make it possible for SQLite to achieve
its aims (
<a class="moz-txt-link-freetext" href="http://www.sqlite.org/draft/lockingv3.html#ext3-barrier-problem">http://www.sqlite.org/draft/lockingv3.html#ext3-barrier-problem</a> ).
When betrayed by lower levels in the stack, a page-oriented SQLite
database is much more likely to end up in a bad way than append-only
file formats or storage distributed over many orthogonal files.
This will be kept in mind.<br>
<br>
Export is a trickier problem. While we can always serve up data as
it was first served to us, additional user-created meta-data may not
map into that format at all or in a standard fashion. For example,
Thunderbird e-mail tags may or may not be persisted into the mbox
storage as a custom header line. While other software may
understand how to interpret this header line, it is not remotely a
standard.<br>
<br>
Andrew<br>
</body>
</html>