client-server

[linas@linas.org]

It's been rumoured that Derek Atkins said:

> Just to play devil's advocate let me throw another log on the fire:
> what we really want here is a distributed file system.  

Before http was invented, these were considered for the web.
Unfortunately, nfs was not secure, and afs was propreitary
& too complex.  Eventually, we realized that ftp would suffice;
but ftp had too much historical baggage, and thus, a clean-slate 
http was needed. The rest is history.  (I was there for the 
actual discusions when this 'communal' decision got made).

(not that people didn't try to build file systems on top of http...)

> We want data
> locking and access control semantics to allow multiple clients to
> access the data store.  Why not just split the data store into
> multiple "files" and require a network file system that allows us to
> lock the files (and directories) when we need to modify data.  

ISAM? DSAM anyone? on top of reiserfs so that one-record-per-file is
feasible?

Ever notice that some sql databases are built on top of isam ??
Makes you say 'hmmm'...


> If the
> File System can encrypt data across the network, doesn't that solve
> our problem, too?

Well, no, because such systems were built in the 60's and they didn't 
work because you need to have the query engine live near the data,
and file systems don't support queries.  Thus, SQL was invented.

I think the example sed in a different email was having to compute
account balances, and how that would need to live 'near' the
database, i.e. a transactional server was needed.

(btw, in 'real' accounting systems, the actual balance is stored,
and is not computed on the fly by totalling up all transactions.
In gnucash, we total it on the fly because that was the easier thing 
to do at the time.)

--linas