Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
Angela Schreiber wrote: but that's a different story isn't it? i was talking about the compliance class (and the method set). Probably. I just wanted to make sure that no time is spent on something that is broken in the spec... RFC 3253 defines a separate behaviour for version-controlled collections. I'm not completely sure what the issue is? A version controlled collection is a specific type of a regular version controlled resource, it just also records information about version controlled children... what i meant: http://www.webdav.org/deltav/protocol/rfc3253.html#version-controlled-collection.feature states the following: As with any versionable resource, when a collection is put under version control, a version history resource is created to contain versions for that version-controlled collection. In order to preserve standard versioning semantics (a version of a collection should not be modifiable), a collection version only records information about the version-controlled bindings of that collection. In order to cleanly separate a modification to the namespace from a modification to content or dead properties, a version of a collection has no members, but instead records in its DAV:version-controlled-binding-set property the binding name and version history resource of each version-controlled internal member of that collection. [...] A version-controlled collection has all the properties of a collection and of a version-controlled resource. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a version-controlled collection. 14.1.1 DAV:eclipsed-set (computed) [...] Clarifying: the difference between a collection and a non-collection with respect to WebDAV versioning is that the version-controlled state of a collection *additionally* includes the binding-set (for the members), but not the members itself. however: the patch provided by jeremi and modified by rob does not distinguish between collections and non-collection resources. in both cases the underlying repository Node is made 'versionable'. consequently both collections and non-collections behave the same way (i.e. like version-controlled resources), which is from my understanding not what the RFC defines. see quote above. do i miss something? Hm, probably I'm partly confused because I've grown up with RFC3253 semantics, and haven't used collection versioning in JCR so far (the system I currently work on only can version leaf files + properties). It seems the counterpart of a version controlled collection in WebDAV would be a JCR node where all children have OnParentVersionAction=IGNORE, meaning they are always version-controlled independently of the parent. I'm not sure whether anything else can be exposed in a RCF3253 compliant way. We may have to ask Geoff for advice :-). Best regards, Julian
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
hi Clarifying: the difference between a collection and a non-collection with respect to WebDAV versioning is that the version-controlled state of a collection *additionally* includes the binding-set (for the members), but not the members itself. jup... and that's currently missing. Hm, probably I'm partly confused because I've grown up with RFC3253 semantics, and haven't used collection versioning in JCR so far (the system I currently work on only can version leaf files + properties). It seems the counterpart of a version controlled collection in WebDAV would be a JCR node where all children have OnParentVersionAction=IGNORE, meaning they are always version-controlled independently of the parent. I'm not sure whether anything else can be exposed in a RCF3253 compliant way. here we go. the simple-server currently leaves it to the configuration to decide which nodes are collections and which are not. potentially any of them can be made versionable in jcr (and currently in dav as well). i don't see a smart solution up to know. a simple one would probably be to ignore the versioning stuff for the collections at all only allow non-collections to be version-controlled resources. disregarding whether the underlying node is mix:versionable or not. leading to the question: will it cause problems if the dav-client can 'see' dav VersionHistoryResources and VersionResources that don't have a corresponding versionable dav resource? or would that be an negligible inconsistency? angela
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
Angela Schreiber wrote: ... leading to the question: will it cause problems if the dav-client can 'see' dav VersionHistoryResources and VersionResources that don't have a corresponding versionable dav resource? or would that be an negligible inconsistency? ... That shouldn't be a problem, because it could also be cause of the VCR being removed, while versioning information was preserved. Best regards, Julian
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
hi jérémi
since i would like to take advantage of your patch to think about a better
structure and how we can package things ('simple' is probably not an
appropiate package name), i would suggest that to have this solved before we
commit the extensions.
hope that's fine.
Sure. what kind of changes you want to do?
i'd like to
- sort out the webdav part from the 'jcr-server'
(see discussion regarding package naming before the
1.0 release).
- separate 'simple' and 'jcr' packages (which are currently
together in the server) and find a solution for those
classes inside the jcr-package that in fact are common
classes for both implementations.
- find a solution for the suggestion mikhail posted yesterday.
basically those 3 issues belong together.
finally i would like to build a basis for further development
of the 'simple' server, which is not simple any more. i think it
would be wise to do this, before we add further extensions to
the 'simple' package.
your patch was a perfect start for this :))
so i'm currently working on an initial proposal in order to
have a discussion basis.
I was not here at the beginning of the week, but i will finish the
IOhandler for the version maybe tomorrow.
no need to hurry. i still owe you a review anyway :).
regards
angela
