Ben Collins-Sussman <sussman@collab.net> writes:
> Hmmm, I'm pondering an even more radical idea, though one that might
> make DAV experts annoyed.
>
> As I said before, ra_dav is the only network implementation that has
> to send tokens with each write request; the other RA layers push them
> into the filesystem at the beginning of the commit.
>
> But what if ra_dav did the same? The first thing we do for a DeltaV
> commit is create a server-side "activity" (which is an fs
> transaction). The whole point of this "activity", as I understand it,
> is to compensate for the statelessness of HTTP; every subsequent
> write request references the activity as the location of the write.
The problem is that DAV is stateless -- you'd have to persist those
tokens beyond the lifetime of an HTTP request (specifically, the
MKACTIVITY one) so they'd be available for comparison as other
requests come in. The connection pool is not a viable option as it
isn't guaranteed to stick around through the lifetime of the commit
operation (server-side controlled by the MaxKeepAliveRequests, IIRC).
Good idea, but would need quite a bit more fleshing-out. For example,
can we store these tokens in the activity database along with the FS
transaction name?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 28 17:14:40 2005