Janne Jalkanen wrote:
On 27 Mar 2008, at 23:28, Murray Altheim wrote:
Janne Jalkanen wrote:
The big question (for me anyway) is whether to implement this as some
kind of actual hierarchical storage structure, or just via metadata.
I think that should be up to the repository; the only thing that
really matters is the reference scheme (and a perceived hierarchy is
as good as any, i.e. /a/b/c).
Uuh. I wish you hadn't said that. I think it should be up to the design,
so that if someone changes a repository it wouldn't matter. One of the
things I think we should aim to permit in 3.0 is a similar variety of
storage provider possibilities. It's likely a big selling point.
Sorry, I don't understand. How would adding hierarchical pages (that
is, pages which are of the form a/b/c both in names and URLs) remove the
ability to pluginize our repository?
Right now out repositories are all flat. Making a fundamental change
that would *require* hierarchical support, iff that support were manifest
as actual page locations rather than simply metadata addresses (i.e.,
if we didn't use a dereferencing 'manager') would exclude a lot of
existing providers. But if we use metadata alone to support hierarchy
(with the addition of an addition record type, Collection), then it
would seem that *any* of the existing provides would work. And, of course,
JackRabbit.
Also, ACL management will be a nightmare unless clear heritance rules
exist.
Oh, they'd exist, but they'd be managed by metadata rather than by
physical storage location. We'd obviously have to restrict how pages
could be contained within Collections, such as perhaps restricting
a page to one parent Collection (which wouldn't be a bad thing, and
likely expected).
Just thinking out loud, really. I've been tootling around some ideas
on how to do this for awhile. About a year ago I modified my XNode
API and implementation* to include an extension of an XNode called
an XNodeCollection, which doesn't have a body, just a list of child
nodes. All metadata. Moving an XNode from collection to collection
is a matter of modifying the XNodeCollection metadata. All
XNodeCollections sit inside one root XNodeCollection. My current
implementation is only one level deep but could theoretically be
deeper.
Murray
* think of XNode as similar to SOAP, an XML document with a
header, body, and repository (for previous revisions). Yes, I
decided to handle revisioning within the model, but that would be
dropped as an idea here.
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
