Jonathan Briggs writes:
> On Wed, 2005-06-01 at 14:43 +0400, Nikita Danilov wrote:
> > Nikita Danilov writes:
[...]
> >
> > That latter bit, about making them persistent, is where the trouble
> > begins: once queries acquire identity and a place in the file system
> > name-space, they logically become part of that very name-space they are
> > querying! This leads to various complication, and you are trying to work
> > around them by claiming that queries are not _always_ part of name-space
> > ("file1 [only] **appears** to be a child..."). This non-uniform behavior
> > is a big disadvantage.
>
> In this scheme, query objects were always part of the name-space.
Then, paths visible through queries are inconsistent with names of
underlying objects. You querying system returns fake results
("/tmp/A/B/C/A/file1") that are not present in the database queries are
ran against. This is *wrong*. Nobody is going to tolerate DBMS that
sometimes returns extra rows in SELECT statement, right?
[...]
>
> The user is responsible for sensible naming. Under normal use, a user
> would hardly notice the difference between traditional directories and
> this name-query system.
Heh, this assumes that users will continue to use new namespace as they
use old one. Which is not true. Usage is determined by features
provided. This is, by the way, one of driving forces behind reiserfs
support for small files and large directories.
If file system provides ability to create namespaces in the form of
arbitrary graphs, this will be used.
Nikita.
