>> -----Original Message-----
>> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, January 21, 2004 10:47 AM
>> To: Slide Developers Mailing List
>> Subject: Re: Indexing store
>>
>>
>> Nick Reddel wrote:
>> >>>>(!) Rather than use interceptors, every method in the
>> adapter that
>> >>>>modifies the underlying RDBMS also reindexes the file.
>> Principally
>> >>>>because my client is mostly interested in the "meta-meta"
>> >>>
>> >>>property of
>> >>>
>> >>>>whether anything (acl, lock, properties) have changed, so as
>> >>>>to cache successfully. Change propogation to children I
>> >>>
>> >>>simply ignored
>> >>>
>> >>>>(because for a relational system, which is what I was
>> >>>
>> >>>after, there's no
>> >>>
>> >>>>such thing as a definitive parent/child relationship).
>> >>>
>> >>>I'm not sure I understand what you mean here, can you
>> elaborate more?
>> >
>> >
>> > OK. By "relational filesystem" I meant a hierarchical view of a
>> > filesystem where the "model" structure , folders & children, is
>> > dynamically constructed from an underlying traditional filesystem,
>> > e.g. a standard Slide store.
>> >
>> > So you can show a view - say
>> > /users/john/recent/projects/myProject
>> >
>> > of the total file system which is filtered to show only files for
>> > which john is the editor and have been modified in the
>> last 10 days.
>> > Sort of like workspaces, but completely property-defined.
>> >
>> > And that "view" (from the data point of view) is just a
>> normal folder
>> > (to the client).
>> >
>> > I've just got it working, and I'm already finding it useful.
>>
>> Sounds interesting. So this is like a view in a releational
>> database?
>> Something like a "froozen" query?
>>
>> Oliver
exactly, except it�s hierarchical (from one point of view a folder
structure is simply a hierarchical property structure). It gets back to
natural language/theory of knowledge - there are various ways you can
conceptually refer to, say, a given document:
e.g. /documents/projects/thisClient/bugs/buglist.xsd
well, it could be found using my "relational store" at
/resources/xsd/buglist.xsd[#31997] {for unique naming on "view" paths
you need a resource-id}
You have to be careful to be orthogonal in your base/physical folder
structure, but if you are, any BINDs you do add pure meta-information to
your document.
A classic example is for web sites: where do you put the resources? Do
you have:
docs- en - client
- products
- cart
- guest
fr - client
- products
- cart
- guest
...
res- css en - client
- products
- cart
- guest
...
png en - client
- products
- cart
- guest
...
There's so much duplication and tedious navigation just here, which is
not necessary if you get a way from a purely physical folder structure.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
