Hi;
Why is this discussion revoling around Relational
Databases. The attributes of the files and files themselves, if were to be
modelled for querying a Realtional Database would really s**k. The
attribute info is neither structured, nor is it unstructured, its
SEMI-STRUCTURED. Exceuting Structured Query Lang(Sql) over semistrutured
data would result in
-> Harder modelling (almost a waste of effort),
-> Complex Quering (Eleganant system of no use because of the amout of joins
that would result in Quering , if you somehow model semi-structured data in
some structured Data Model);
The best option, to start would be with best COT. I feel
we should look at Loreal a stanford project. For hints about modelling our
"whatever".
Regards
Faraz :)
----- Original Message -----
From: "Nikita Danilov" <[EMAIL PROTECTED]>
To: "Jonathan Briggs" <[EMAIL PROTECTED]>
Cc: "Hans Reiser" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"Alexander G. M. Smith" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<reiserfs-list@namesys.com>; <[EMAIL PROTECTED]>; "Nate Diller"
<[EMAIL PROTECTED]>
Sent: Thursday, June 02, 2005 4:54 PM
Subject: Re: File as a directory - VFS Changes
> Jonathan Briggs writes:
> > On Thu, 2005-06-02 at 14:38 +0400, Nikita Danilov wrote:
> > > Jonathan Briggs writes:
> > > > On Wed, 2005-06-01 at 21:27 +0400, Nikita Danilov wrote:
> > > > [snip]
> > > > > Frankly speaking, I suspect that name-as-attribute is going to
limit
> > > > > usability of file system significantly.
> >
> > Usability as in features? Or usability as in performance?
>
> Usability as in ease of use.
>
> [...]
>
> >
> > A index is an arrangement of information about the indexed items. The
> > index contents *belong* to the items. An index by name? That name
> > belongs to the item. An index by date? Those dates are properties of
>
> In the flat world of relation databases, maybe. But almost nowhere else
> improper name is an attribute of its signified: variable is not an
> attribute of object it points to, URL is not an attribute of the web
> page, block number is not an attribute of data stored in that block on
> the disk, etc.
>
> [...]
>
> >
> > In the same way that you can descend a directory tree and copy the
names
> > found into each item, you can check each item and copy the names found
> > into a directory tree.
>
> Except that as was already discussed resulting directory tree is _bound_
> to be inconsistent with "real names".
>
> >
> > >
> > > Indices cannot be reduced to real names (as rename is impossible to
> > > implement efficiently), but real names can very well be reduced to
> > > indices as exemplified by each and every UNIX file system out there.
> > >
> > > So, the question is: what real names buy one, that indices do not?
> >
> > By storing the names in the items, cycles become solvable because you
> > can always look at the current directory's name(s) to see where you
> > really are. Every name becomes absolutely connected to the top of the
> > namespace instead of depending on a parent pointer that may not ever
> > connect to the top.
>
> But cycles are "solvable" in current file systems too: they simply do
> not exist there.
>
> >
> > If speeding up rename was very important, you can replace every
pathname
> > component with a indirect reference instead of using simple strings.
> > Changing directory levels is still difficult.
>
> It is not only speed that will be extremely hard to achieve in that
> design; atomicity (in the face of possible crash during rename), and
> concurrency control look problematic too.
>
> >
> > --
> > Jonathan Briggs <[EMAIL PROTECTED]>
> > eSoft, Inc.
>
> Nikita.
>
