Re: Relationship between BIND and RFC 3253
Werner Donné <[email protected]>
| Newsgroups | gmane.ietf.webdav |
|---|---|
| Message-ID | <[email protected]> |
Hi Julian, Why is it only valid inside a workspace? Best regards, Werner. On 07 Oct 2008, at 14:24, Julian Reschke wrote: > Julian Reschke wrote: >> OK, >> proposed text (see also <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.relation-to-deltav >> >): > > ...in the meantime I realized that this is only true if it happens > inside a workspace. New version (changing the intro and the paths): > > 10. Relationship to Versioning Extensions to WebDAV > > Servers that implement Workspaces ([RFC3253], Section 6) and Version > Controlled Collections ([RFC3253], Section 14) already need to > implement BIND-like behaviour in order to handle UPDATE and > UNCHECKOUT semantics. > > Consider a workspace "/ws1/", containing the version-controlled, > checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ > CollY", and a version-controlled resource R, bound to C1 as "/ws1/ > CollX/test": > > +-------------------------+ > | Workspace | > | bindings: | > | CollX CollY | > +-------------------------+ > | | > | | > | | > +---------------+ +---------------+ > | Collection C1 | | Collection C2 | > | bindings: | | | > | test | | | > +---------------+ +---------------+ > | > | > | > +------------------+ > | Resource R | > +------------------+ > > Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but > undoing the checkout on C1 will undo part of the MOVE request, thus > restoring the binding from C1 to R, but keeping the new binding from > C2 to R: > > >> Request: > > MOVE /ws1/CollX/test HTTP/1.1 > Host: www.example.com > Destination: /ws1/CollY/test > > >> Response: > > HTTP/1.1 204 No Content > > >> Request: > > CHECKIN /ws1/CollY/ HTTP/1.1 > Host: www.example.com > > >> Response: > > HTTP/1.1 201 Created > Cache-Control: no-cache > Location: http://repo.example.com/his/17/ver/42 > > >> Request: > > UNCHECKOUT /ws1/CollX/ HTTP/1.1 > Host: www.example.com > > >> Response: > > HTTP/1.1 200 OK > Cache-Control: no-cache > > As a result, both C1 and C2 would have a binding to R: > > +-------------------------+ > | Workspace | > | bindings: | > | CollX CollY | > +-------------------------+ > | | > | | > | | > +---------------+ +---------------+ > | Collection C1 | | Collection C2 | > | bindings: | | bindings: | > | test | | test | > +---------------+ +---------------+ > | | > | | > | | > +------------------+ > | Resource R | > +------------------+ > > The MOVE semantics defined in Section 3.15 of [RFC3253] already > require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the > same version history (as exposed in the DAV:version-history > property). Furthermore, the UNCHECKOUT semantics (which in this > case > is similar to UPDATE, see Section 14.11 of [RFC3253]) require: > > ...If a new version-controlled member is in a workspace that > already has a version-controlled resource for that version > history, then the new version-controlled member MUST be just a > binding (i.e., another name for) that existing version-controlled > resource... > > Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to > the > same resource R, and have identical DAV:resource-id properties. > > BR, Julian -- Werner Donné -- Re http://www.pincette.biz Engelbeekstraat 8 http://www.re.be BE-3300 Tienen tel: (+32) 486 425803 e-mail: [email protected]