incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <>
Subject Re: JSPWiki 3 design notes
Date Tue, 05 Feb 2008 13:04:45 GMT
Janne Jalkanen wrote:
>> 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
> Actually, I disagree.  This is problematic, if you move the page
> around.  Therefore, it's better to use a synthetic property like
> jcr:uuid, which does not necessarily bear any relation to the path of
> the object.

Well, if by jcr:uuid you mean a canonical, unique identifier for the
resource, I've got that as an 'oid' (object id), created by a 10ms
delayed, non-repeating (timestamped) ID factory. The system identifier
is the *current* location of the page. When moved to the trash the
system ID is transferred to DC.source, and if restored from the trash
its default location is recovered from DC.source. The uuid/oid is
only useful in determining the canonical identifier for the resource,
which is a kind of name, not an address.

>> In my system the page revisions are stored within the document record.
> It is useful to look at Mediawiki's storage model; they have a
> separate table for archived versions for optimization purposes.  This
> suggests it might make sense to keep the version history outside of
> the actual Node.  (Which is, incidentally what jcr does as well - the
> version history is exposed as /jcr:system/jcr:versionHistory/<node>)

Yes, I'm aware of that. This was a design decision based on portability
of the document and revisions as a package.

>> 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 think that this suggests that we should keep our own identifier
> system and leave dc:identifier for user use.

Only if we plan to use DC.identifier (or okay, dc:identifier) for things
like metadata records of external resources. It's fine for JSPWiki, as
that's its intended purpose, i.e., an identifier for a resource/wiki

>> 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.
> Well, yes, there is, and I've told you about it already ;-)

If you're talking about the prototype we've discussed, I mean more
information about the ability to continue to use non-JSR 170 backends,
as we may need to. We may have a very strong need to if we end up
backing the system into a CMS (which I wouldn't particularly like but
it might not work with our archiving system otherwise, dunno yet).


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