incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: [jira] Updated: (JSPWIKI-454) Export tool
Date Sun, 22 Mar 2009 11:27:05 GMT
> Some ideas come to my mind for the versioning issues...
> * If no representation is defined for history in JCR, why did we  
> choose this "standard"? History is a major characteristic of Wiki...

There is.  It's just that the JCR spec does not define a standard way  
of importing a version history from an XML tree. It *should* probably  
work if we import into jcr:versionHistory.

> * Is it possible to represent an "object in history" as an object in  
> JCR?

Yes.  JCR spec uses /jcr:system/jcr:versionHistory to point at all old  
versions of an object.

Assuming you want to use JCR versioning - there are a few reasons why  
that might be a bad idea in our context. For example, any  
modifications to page attributes will cause a new version to be  
formed, unless we keep a separate non-versionable subtree of the page  
metadata-which-is-not-to-be-versioned.

I have not yet decided what the best way to deal with this is. I plan  
to corner some JCR experts next week at ApacheCon and ask for their  
opinion.

> In other words, to add paths information to designate an "historical  
> object" instead of a current object?

This is possible no matter what solution is chosen, since everything  
is represented as a Node in JCR.

> * Another solution would be to say that a "Wiki page" (or  
> attachment) is not a JCR leaf object but a JCR path (directory)  
> containing "current" for the current version, "1" for version 1, etc.

All WikiPages are already JCR Nodes. This means that it is possible to  
store arbitrary metadata (or metadata trees) under them. One option  
I've been playing around with is building our own version storage with  
versions stored under wiki:versions. Another is to have a / 
wiki:oldVersions tree. Third is to use the JCR built-in versioning.

> somebody would be kind enough to point me to a document explaining  
> the real advantage of JCR compared to a "regular" file system?
> Is it only to remove the (sometime very deadly) differences between  
> Windows and Unix file system?
> If true, a simple file name marshaller/unmarshaller would be enough,  
> isnt'it?

JCR provides content management back-end which can provide us things  
like HA, clustering and very rich metadata. A file system is a file  
system which essentially provides key-value mapping and that is all :-)

/Janne

Mime
View raw message