RE: re-use of version URL's

>    From: "Mark A. Hale" <mark.hale@interwoven.com>
>
>    > ... It would be very easy for that system to include 1.20
>    > into the temp space's URL. That would effectively avoid reuse.
>
>    Yes, and we could maintain a system that remembers everything
> and becomes
>    slower with time and consumes more memory.
>
> There is no reason for the system to remember everything.
> It can just generate a GUID that it both:
>
> - tacks onto the end of the version URL
> - stores as a property (e.g. the "version-urlifier property) of
> that version
>
> You can then re-use names in your underlying store, e.g.
>
>    /write.c/temp/synchronous/1.0
>
> but the version URL is:
>
>    http://someWebDAVServer.com/write.c/temp/synchronous/1.0;07592
>
> When somebody asks you later to do something to the resource at this
> URL, you first check whatever resource is at your store in:
>
>    /write.c/temp/synchronous/1.0
>
> If it has "07592" as it's version-urlifier property, then all is
> well, and you operate on that resource.  If it has any other value
> in its version-urlifier property, you return 404 - Not Found.
>
>    The original use case I presented had the following:
>
> 	   In addition, the temporary spaces are completely deleted
> and are not
> 	   maintained anywhere in the server.
>
>    This is part of the story I presented and is a highly
> reasonable scenario.
>
> I agree, but you can use the above technique to ensure that the
> version URL's are stable, without the overhead of remembering
> everything.

I understand where you are coming from.  The need to remember as described
in my example comes from the fact that the temporary resources and
everything pertaining to them is deleted.  I am using this as a the semantic
meaning behind the use of a temporary space for the example I posed.

	Thanks,

	Mark

Received on Thursday, 4 January 2001 17:36:09 UTC