Janne Jalkanen wrote:
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
Check out the JCR spec on this one. It's a globally unique ID of a
Node.
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).
I think the chances of using a non-JCR backend is essentially zero,
because it would mean duplicating the entire metadata layer and
essentially redesigning JSR-170.
So you don't see any way of using a JSPWiki 3.0 implementation
*without* JSR-170? I'm rather surprised, really. One of the real
strengths of JSPWiki is that there's a nice, lightweight file
system implementation too. If the entry ramp is a complex database
that'll likely have huge significance on its use. For example, I've
been working on a lightweight wiki for the OLPC XO (kids') laptop.
It runs fine using the file system but could *never* use a complex
database since the whole shebang must fit into memory.
But this is a very long topic and I don't have more time...
Agreed -- right now neither do I. But we're not necessarily in a
rush either...
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
