incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <murra...@altheim.com>
Subject Re: JSPWiki 3 design notes
Date Tue, 05 Feb 2008 04:15:15 GMT
Janne Jalkanen wrote:
>> The document is assigned a new system identifier when in the trash, with
>> its original stored as metadata (e.g., "DC.source").
>>
>> If the document is reinstated from the trash, its original system
>> identifier is used to relocate it (with of course the possibility that
>> a new page with the same address now exists, and the requisite handling
>> of that situation).
> 
> Ah, that's actually kinda neat.  Yeah, that would work.  Thanks Murray!
> 
> If the Trash is per-wikispace, it should work nicely.

You don't really need that though. The system identifier for the page
should include its full path. In my systems I use a collection/document
metaphor, with the wiki application name being used as the collection
name, the wiki page name as the document identifier. All documents get
their own internal URL that contains the full context

    xnode://db/wiki/Main
    xnode://db/wiki/RecentChanges

[Ignoring the 'xnode:' protocol for the moment] when a document is
deleted, I provide the option to move it to a 'trash' collection,
populating the contents of its DC.source metadata field with its
current system identifier (DC.identifier). If the user restores the
document I use the DC.source to put it back where it used to be. The
only downside of this is that I'm overwriting (losing) any contents
of the DC.source field. But that's a side issue.

(i.e., I long ago solved this issue within my own systems).

> What if just individual versions of a page are removed?  Of course, if 
> the wiki:Trash/<identifier>/DC:source points directly to the 
> corresponding version node, then it probably shouldn't really be a big 
> problem...

In my system the page revisions are stored within the document record.
I think this is going to vary depending on the backend used. I store
the entire contents of the document metadata along with each revision
(just copying the entire metadata set into the <head> of the revision),
so this isn't a problem.

One issue for me is that I have previously been using DC.identifier to
store the system identifier for each page, but I've decided to create
a new field (within my own application profile) for 'system id' and
use DC.identifier for things like ISBNs, since my metadata records can
sometimes refer to a physical or digital resource that isn't stored
directly in the system. That's probably not an issue here either.

I must admit I'm a bit concerned that the 3.0 design might lock out a
large number of existing backend implementations (including my own) with
a requirement to use the JSR-170 backend, since currently there are
variety of options, and we might assume we don't even know about the
custom ones that people have created. I'm working on a major project
that *might* migrate to JackRabbit but might not. If not, I'll still
need a way to use 3.0 with our systems. The XNodeProvider (Berkeley JE
based) is currently our way forward and I'm not in a position to scrap
that. So if there's plans to provide a non-JSR-170 backend -- in other
words we'll still have a WikiProvider API -- I'd like to know more about
those plans.

Cheers,

Murray

...........................................................................
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



Mime
View raw message