> 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