- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 18 Jan 2002 08:11:55 -0500
- To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
Yes, a scenarios document is badly needed. Anyone who is willing to start such a document will be doing a valuable service. Currently, most of the time available to the designers of the DeltaV protocol for standards-related work is focused on getting the Java binding to DeltaV defined (WVCM: JSR-147), but when we get that done, I hope to have some subset of us focused on the scenarios document. It would be great if we could do both, but realistically, we all have "real jobs" that we need to spend at least some of our time doing (:-). Until then, please keep those scenario questions coming to the mailing list, since that makes the email archive a significant source of information, and is likely to find its way into both the FAQ and the scenarios document. Cheers, Geoff -----Original Message----- From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com] Sent: Friday, January 18, 2002 3:36 AM To: Ietf-Dav-Versioning (E-mail) Subject: RE: Problems with Delete of a version-controlled collection By the way: My experience with the DeltaV Spec is that many people have problems to actually understand what can be done using DeltaV. In my oppinion it is mainly a misunderstanding. Most people I talked to to "sell" DeltaV expect the spec to describe how the can use DeltaV to have some versioning done. They wish to have more examples, even the not so simple ones, provided with the spec. (I for myself did to!) Sure it is not the task of a spec to explain use cases. It would puff up the whole thing. But what about the Szenarios document that is on the DeltaV Homepage? This would be the right place for such use cases or best practices. Why isn't this pursued anymore? P.P.S: An answer to Tim: I will eventually put all my "a ha"'s on the FAQ (so I have an archive for my questions ;o) ). But it will take some time (I have to find a time slot to do this reasonably).
Received on Friday, 18 January 2002 08:12:57 UTC