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
