I don't feel quite passionately enough about this issue to pursue it
with much more vigor, but will make one remaining point:
On Oct 17, 2007, at 6:58 PM, Ian Hickson wrote:
On Mon, 15 Oct 2007, Brady Eidson wrote:
In some embedded (and client-server) database implementations -
including SQLite - continuing to operate on a database that is
known to
be corrupt can lead to the process crashing. Unlike the "CPU core
just
overheated" case, it is a dangerous state software can help avoid.
Ok... but why can't the software simply avoid corrupting the
database in
the first place?
Let's make the assumption that all User Agents are infallible. There
will never be a software bug in code that is specifically part of the
browser that is exposed to the hosted application. This is an
unrealistic assumption, but lets make it for the sake of argument.
However, some things are outside of the user agent's complete control.
Say disk space, for example. We just added an error code that means
"the disk is full." The disk is an external entity the user agent
doesn't have complete control over, and therefore the user agent - and
potentially applications it hosts - have to be ready to handle these
external forces.
Corruption in the database isn't the fault of the user agent. I
consider it at the same level as corruption on disk - or even a full
disk!
As I consider these to be similar, I assert that database corruption
is an external force the user agent - and potentially the application
it hosts - needs to be ready to handle.
There's a line between the user agent and application. *Obviously*
the user agent has to gracefully handle corruption, but I seem to be
the only person on the side of the line where the hosted application
gets to participate in handling the corruption case.
You've already alluded to a list of concerns for version 2 of the spec
that can be addressed based on real world experience with version 1 in
the wild. Perhaps we can put this concern on the v2 list, and put
this thread to rest. ;)
Thanks,
~Brady
