Greg Hudson <ghudson@MIT.EDU> writes:
> Essentially, DAV requires some "batons" to be remembered and passed
> back to it in order to operate. We could synthesize the values from
> available information by picking a convention (the activity could
> probably be some fixed string relative to the repository, and the
> version resource could be synthesized from the URL and version in the
> entries file), but that would be another place where we'd be breaking
> compability with other DeltaV servers.
>
> It's a tricky problem. I'd certainly be happier if the network layer
> could operate without keeping any extra state between operations, but
> that doesn't seem possible for DAV/DeltaV. (At least, not
> efficiently; presumably you could get ahold of appropriate version
> resources by performing some sequence of queries.)
Hmm... Could you drill down on this some more?
I was also hoping for a solution whereby these property names would be
computed from local data in some reproducible way. Or, whether
computed from local state or not, the name would be stored in
someone's baton (an edit baton?), and would be maintained strictly
internally to whoever uses that baton. That way, the id could still
be kept consistent across several calls of [something], even though it
was generated at some point.
But I don't really understand the issue well enough, so I'm just
blathering. :-) I've read webdav_usage.html, but if it addresses this
issue, I missed it.
-K
Received on Sat Oct 21 14:36:18 2006