incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <>
Subject Re: sub pages
Date Thu, 27 Mar 2008 22:27:15 GMT
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,

> 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


* 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>                           ===  = =                                     = =  ===
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

View raw message