Re: [9fans] web-based plan 9?

[a@9srv.net]

On db ↔ fs conversions:
// datas (and their relations) MUST be kept consistents.

there's two things you could mean here: either the
relations between the data fields/types or the relations
between their values. SQL databases are interesting
because they don't do anything to keep the relations
consistent, at a schema level. there are some cases where
this is valuable, but most of the time it just puts more of
the burden on the application.

enforcing consistency between values is a whole different
matter. i don't think that belongs in the database layer of
an application, but on the application side. why let the ap
shove bad data at your DB? bad for scalability (if your DB is
complex enough to need that kind of consistency checking,
it's likely that it's a performance bottleneck alread), bad for
security/stability (why let mallicious attackers fuzz your
DB?), and largely needs to be done in the ap anyway (say
your DB rejects a submission; are you just giong to panic,
say "try again", or try and figure out what it didn't like?).

// And MUST be updated frequently, in transaction.

just curious: what is it about "transactionality" that you care
about? atomicity, logging, roll-back (atomic roll-back)?

// Application code cannot do that, since it's too subject to
// modifications...

i'm not convinced. you can simply... not modify it! unless
you've got a database you're exposing to multiple parties
and you're worried one is going to mess things up for
others, but in that case i think exposing the database
directly is pretty risky regardless.

the application i've worked on with the most complex data
constraints had an "ontology layer" that everything that
wanted to do data access went through. the rest of the
application got to ask very simple questions about what it
wanted, or make very simple updates, and the ontology
layer made sure everything was consistent before talking to
the database. you get the benifits of having that work be
centralized, not related to the core application logic (and
thus not touched when ap logic changes), and you have a
much better idea of what went wrong when a constraint
failed.

// Moreover such a dbfs should allow rapid development of
// views over data (with different permissions) by simply
// write the query in a file and then open the file for reading
// the XML.

somewhere around here i've got a /chan/pq for inferno that
makes connections to a pq database. each open is a new
logical connection; you write the query and read the result.
results were not in XML, and pq has no updates (at current).

i think you've got some very interesting ideas on sessionfs
in particular. i have more thinking to do there.

oh, probably an aside: from an application design point of
view, DO NOT empty my shopping cart just because my
session timed out. i should be able to pick up where i left
off. i'm not sure how hypothetical that example was, but
that's a common source of irritation for online shopping.