On Wed, 2005-06-01 at 18:42 +0400, Nikita Danilov wrote:
> 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?If you wished to enforce name-query directories always having a single name and their query always being identical to their name, then that wouldn't happen. However, query directories (or "smart folders") will have this namespace problem in every case and there is no avoiding it. If the query is for every file modified in the past day, the file path through the query directory is not going to match any given name of the file. Same for keyword queries, ownership queries, or whatever. In the traditional directory system, a file doesn't have an official name, just links to it from directory entries. Perhaps if you think of the proposed "name" meta-data as a "preferred name" the idea would work better for you? -- Jonathan Briggs <[EMAIL PROTECTED]> eSoft, Inc.
signature.asc
Description: This is a digitally signed message part
