* Giacomo Tesio <giacomo@tesio.it> wrote:
Hi,
Hi! Thanks for your reply.
A premise: I'm not talking about developing a web forum or the like.
I'm
talking about a framework to develop large applications with "thin
clients" (as many call the browsers... :-D) which have more complex
requirement than a web forum.
Forums, I think, don't need a database... (even if a database _could_ increase developers productivity)
> The scope is to be able to query the db towards a filesystem, with no need
> to use different libraries for different db backend... each application
> would use a filesystem, while each rdbms would have it's own filesystem (all
> with the same structure, obviously)
That's a really good idea. But there's still one problem to solve:
filesystem hierachies and relational algebra are fundamentally
different concepts. So, if you don't want to just the fs as some
universal sql-transport, data has to be modeled differently.
Well... to keep things simples, yes...
I thinks there's no need to reinvent the wheel, since SQL is so diffused.
And, thinking a bit more, I'm wondering whether v9fs could help to build such a filesystem on linux (where PostgreSQL run) and expose it to plan 9 clients
(actually I don't know what v9fs is and how it works... it would be "easy" to develop a fuse synthetic filesystem for this, but exporting with v9fs it would introduce an unnecessary layer, so build directly in v9fs would be better, if possible).
I'm thinking about a (new) "real world" application of plan 9.
In the "real world" I know, men's productivity is really important (80% of the costs)
Without insult for anyone, I don't want to get a new "toy" for university research... (even I would be glad to work with students on it), I want something which could improve seriously the productivity of a real team (with eterogeneous skills) on reals web applications development.
A forum or a web calendar is not (per se) such a real application.
With all the forums out there, it would be more a didactical hack.
Actually, in many webapps, the real underlying models are neither
relational nor hierachic, but most times just happen to be
modelled relatiolally, because rdmbs'es are the tool of choice
for most people.
Aren't they?
So what we have to do here is to get back to the original problems
to solve and think about how they could fit into an hierachy
instead of relation.
...
Okay, we've got some more data, eg. profile information, maybe all
the other "web-2.0" stuff (user galleries, friend relations, etc),
but IMHO this all easily fits in hierachies if we start thinking
afresh with a blank paper.
...
That's all possible, if we just can imagine it :)
You're right, and I'm sure it would be a wonderful research.
Actually I've also thinked about such a solution (well... more or less) and came to BerkleyDB XML.
Take a look to it. It could be a good source of ideas.
Simple example: a web-forum.
Too simple. In previous post I talked about an ecommerce, and yet I was thinking it was a too simple example.
BTW, if you miss a post on a forum, you would be hungry.
But what if you pay for and order without receving the product you paid for?
> Both are really important.
>
> When a product change its code (aka pk) for business' reasons, I need have
> it changed automatically in any place its referred in the database.
> Or if a dumb employee try to delete a product category (supposing he's
> allowed) I have to be sure that the remaining data don't loose meaning.
That's exactly what constraints, rules in SQL etc are for.
Maybe some similar ruling system for filesystems would be fine :)
(any suggestions ?)
Mmm.. I'm not sure.
Too complex, for a _file_system.
> Application should HANDLE data.
> But datas are a rapresentation of a reality which have a meaning!
> A relational database don't have to know how datas are collected or used.
> But it has to keep meaningfull the rappresentation.
Right. But the database has to know rules which data has to comply,
so a wide range of errors becomes impossible, mathematically provable.
Sure. It was what I was tring to say... sorry for my english! :-D
This is WHY relational database are needed: to be istructed to check for data integrity/consistency.
> I need to be able to atomically save related tuples in different tables,
> since (for example) those different tables could be simply modelling ONE
> real entity (say an order or a family).
CREATE RULE .. AS ON INSERT TO ...
Again, a rule system for filesystems would be really cool :)
I think that rule (or triggers) on any filesystem would be too complex.
You would loose the simplicity of the paradigm.
But I must admit that omero (completely offtopic here) make me think a bit about such a thing: what if we could add to each element interface/file events in the form of rc scripts?
Say you have a button in the interface: the button is a directory (that's what I've understood, never tried), what if when the button is cliccked the click.rc script be executed?
Well... may be this is actually done. Or there may be optimal reasons to avoid this.
It was just an idea.
But it seem to me wrong to generalize such a system.
You would loose in simplicity, which is what make Plan 9 concepts so good!
Giacomo Tesio