Hi Christophe, > 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...
Of course there is one! The point is that a wiki only contains a linear history, but JCR defines a version management which has powerful features like branches and so on. This is no restriction from the application point of view, simply quite hard to implement from the repository point of view. > * Is it possible to represent an "object in history" as an object in JCR? > In other words, to add paths information to designate an "historical > object" instead of a current object? Sure, there are standardized methods for accessing older versions. > As one may not want to add constraints on names and paths (with > conventions like $$$X at the end of the name means version X: this > precludes names containing $$$), may be we can have a root level: > /current/ would be the root level for all current pages > /1/ would be all versions 1 of pages > /2/ all versions 2 > ...etc... > May be this is very bad in terms of access performances? Not sure if I understand you right, but this is a question of the application layer, not the data layer, isn't it? > * 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. This is a solution for the case one decides not to use the JCR versioning feature. > JCR would be (remain?) a kind of file system: > 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? It's more! Have a look at http://www.slideshare.net/uncled/introduction-to-jcr Especially slide #21 will answer your questions! Best regards Florian
smime.p7s
Description: S/MIME Cryptographic Signature
