- From: Juergen Reuter <reuter@ira.uka.de>
- Date: Sat, 10 Feb 2001 03:05:55 +0100
- To: lisa <lisa@xythos.com>
- cc: reuter@ira.uka.de, ietf-dav-versioning@w3.org
> 1) Is anybody planning to implement a client that will interoperate > against a CORE server, not requiring any advanced options to be there at > all? One of the intentions of the protocol is that versioning-unware clients will interoperate against any DeltaV server, including a core server without any advanced options at all. Of course, if you want to write a server that is intended to support a serious number of different clients, then you probably will have to implement some of the options. > 3) Is anybody planning to use NONE OF these options: > - working resource option > - client workspace option > - Workspace option As for clients, same answer as for 1), i.e. (at least) any versioning-unware client. > In other words, is anybody planning to expose the results of > work-in-progress, on the VCR, to all clients doing read operations? If I understand you correctly, this is a different question, because even fully-fledged clients may (e.g. by the user's choice) decide not to use any of the above options. So, actually, the answer must always be yes for any combination of a server and client. > 4) Can a client that does the checkout option but not the "working > resource" option operate against servers with the "Working Resource" > option? Yes, but it can only work on the resource that is checked out under the URL of the VCR, since it does not know the URLs of the working resources. > 5) Can a client that doesn't know about the UPDATE option interoperate > with VCRs that have had UPDATE applied to them? Yes, but if the server does not allow forking at the selected version, the client can not create a new version until another proper update is issued. > - what happens if the client does not support this option but the > server does, The client then simply does not use the option. But it may possibly not be able to handle resources that have been created/modified by different clients that use that option (such as accessing working resources or creating a new version on an updated VCR where forking is not allowed). > - what happens if the client supports this option but the server does > not, The server must reject the according request. The client should explore the server's capabilities via the OPTIONS method before requesting any optional behaviour. > - whether clients that do not support this option can interact with > clients that do support this option (I mean, whether both kinds of > clients can do operations freely on the same set of resources, on a > server that does support the option). In general, no (cp. again 4) and 5)). > - If a server implements this option at all, the client must ALSO > implement this option in order to interoperate. I would regard such a constraint as a bug in the protocol, since a server option never might enforce the client to implement anything. > - This option is only used when the client requests it. The server > that implements this option MUST also support the case where the client > does NOT request this option, in order to interoperate with clients that > do not support this option. I think this just describes some general requirements of a 'server option'; it should always be that way. > - A VCR on which this option has been used (e.g. UPDATE) MUST > interoperate with clients that are unaware of the option. That is something that you almost never can achieve in general; see for example the above answers on 4) and 5). The problem here is, that you implicitly want to have interoperability between different clients that use different options. This is only possible if you can map complex options on simpler requirements. For example, HTTP defines an optional header that allows to GET only a range of bytes from a document. This can be mimicked by the more simple required GET without this header by getting the whole document and throwing away all the data that is not needed. > - If any clients on a system use this option (e.g. Merge), whether > clients that do not understand the option (e.g. Merge) will be able to > use the resources on the system. In the case of Merge, yes; in general (e.g. working resources, update) no. Greetings, Juergen
Received on Friday, 9 February 2001 21:06:16 UTC