- From: Edgar Schwarz <Edgar.Schwarz@marconi.com>
- Date: Fri, 26 Apr 2002 15:39:49 +0200
- To: ietf-dav-versioning@w3.org
Hallo Stefan, Stefan Eissing schrieb: > Am Freitag den, 26. April 2002, um 13:06, schrieb Edgar Schwarz: > > So a clever autoversioning server could assume that b was a > > temporary file which > > can be thrown away (Also deleting the autoversioned history) and > > autoversion a. I forgot to state a precondition: The client is telling who it is in the HTTP request. If this is wrong please stop reading :-) > The problems with this are: > - the server is guessing on the intention of the client - this > could be wrong If you know the client you probably can make a very educated guess. > - Only after DELETE b, the server could guess that the new a is the next > version of the former a (now b). Naturally, this just would mean that you have to delete the version history you just created. > - Before DELETE b, the new a is either a unversioned resource or a > VCR with its own, new version history. > - The situation gets easily messy if someone does a PROPPATCH a > before DELETE b. If a is a VCR at that time, autoversioning strikes > again and a has 2 versions. Both versions need to be applied > to the version history of the "old" a... I agree that the situation can become messy. What I just want to say is: IF the client which is causing the problem with an autoversioning server doesn't hide it's identity AND IF the solution to forbid this client write access isn't acceptable THEN it could be possible to give it some special treatment by recognizing certain request patterns. Mit freundlichen Grüßen / Best regards Edgar Schwarz -- Edgar.Schwarz@marconi.com, Postf. 1920, D-71509 Backnang,+49 7191 13 3382, Marconi Communications, Access Division, Quality and Process Improvement Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag (Niklaus Wirth). Make it as simple as possible, but not simpler (A.Einstein)
Received on Friday, 26 April 2002 09:40:26 UTC