On Fri, Dec 29, 2000 at 03:24:47PM -0600, Karl Fogel wrote:
> 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.
This is not for runtime state. During an "update" or "commit" or whatever,
we *do* use batons.
We store state from an update so that we can properly commit later on.
As GregH said, there is no way for the client to manufacture a version
resource URL, so we must store that on the client side. We also need to
store the location on the server where we'll create an activity. It is
simply part of the mechanism for this RA layer.
I asked you about this a while back. "I have RA-specific properties, where
do I put them?" And you said to put them into the WC property store. So I
did, but that raises the issue of how to access them during the commit
process (the original issue of this thread).
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:18 2006