2008/10/15 <sussman_at_tigris.org>:
> Author: sussman
> Date: Wed Oct 15 12:01:46 2008
> New Revision: 33660
>
> Log:
> * notes/http-protocol-v2.txt: evolve this a bit more.
>
> Modified:
> trunk/notes/http-protocol-v2.txt
>
> Modified: trunk/notes/http-protocol-v2.txt
> URL: http://svn.collab.net/viewvc/svn/trunk/notes/http-protocol-v2.txt?pathrev=33660&r1=33659&r2=33660
> ==============================================================================
> --- trunk/notes/http-protocol-v2.txt Wed Oct 15 11:46:28 2008 (r33659)
> +++ trunk/notes/http-protocol-v2.txt Wed Oct 15 12:01:46 2008 (r33660)
> @@ -3,8 +3,8 @@
> GOAL
> ====
>
> -Write a new HTTP protocol for svn, one which is entirely proprietary
> -and designed for speed.
> +Write a new HTTP protocol for svn -- one which is entirely proprietary
> +and designed for speed and comprehensibility.
>
>
> PURPOSE / HISTORY
> @@ -19,47 +19,53 @@ value propositions:
> C. Standardized encryption (SSL)
> D. Excellent logging
> E. Built-in repository browsing
> - F. Interoperability with other WebDAV clients
> - G. Caching within intermediate proxies
> + F. Caching within intermediate proxies
> + G. Interoperability with other WebDAV clients
>
> Unfortunately, DeltaV is an insanely complex and inefficient protocol,
> and doesn't fit Subversion's model well at all. The result is that
> -Subversion speaks a "limited portion" of DeltaV, and pays a huge price
> -for this complexity: speed.
> +Subversion speaks a "limited portion" of DeltaV, and pays a huge
> +performance price for this complexity.
>
> A typical network trace involves dozens of unnecessary turnarounds
> where the client keeps asking for the same information over and over
> again, all for the sake of following DeltaV. And then once the client
> has "discovered" the information it needs, it often ends up making a
> custom REPORT request anyway. Most svn operations are at least twice
> -as slow over HTTP than over the custom svnserve protocol.
> +as slow over HTTP than over the custom svnserve protocol.
>
> +The existing HTTP protocol is also devilishly hard to comprehend or
> +extend, since it requires understanding of the DeltaV spec, and
> +exactly to what partial-degree we support that standrd.
>
> -PROPOSAL
> -========
> +
> +REQUIREMENTS
> +============
>
> Write a new HTTP protocol for svn ("HTTP v2"). Map RA requests
> directly to HTTP requests.
>
> - * svn over HTTP should be much faster (eliminate turnarounds)
> + * svn over HTTP should be much faster (eliminate extra turnarounds)
>
> * svn over HTTP should be almost as easy to extend as svnserve.
>
> * svn over HTTP should be comprehensible to devs and users both
> (require no knowledge of DeltaV concepts).
>
> - * svn over HTTP should be designed for optimum cacheability by
> - proxy-servers.
> + * svn over HTTP should be designed for optimum cacheability by web
> + proxies.
> +
> + * svn over HTTP should make use of pipelined requests when possible.
>
>
> MILE-HIGH DESIGN
> ================
>
> - * Write new mod_svn module. Design it to run side-by-side with
> - mod_dav_svn on the same public URI.
> + * Write new mod_svn module. Design it to (optionally) run
> + side-by-side with mod_dav_svn on the same public URI.
>
> - * Extend libsvn_ra_serf to detect the Apache feature and if present,
> - speak the new protocol.
> + * Extend libsvn_ra_serf to detect the new Apache protocol and if
> + present, use it.
>
> * Client/server compatibility:
>
> @@ -76,10 +82,9 @@ MILE-HIGH DESIGN
> get better HTTP speed".
>
> In theory, mod_svn should operate completely standalone (and should be
> -tested this way.) If an admin wants to support older clients, or add
> +tested this way.) If an admin wants to support older clients or add
> webdav functionality (such as autoversioning), then mod_dav_svn can be
> -installed "behind" mod_svn.
> -
> +installed "behind" mod_svn at the same URI.
>
>
> DESIGN
> @@ -98,7 +103,7 @@ DESIGN
> and maximum version number of the protocol it understands.
>
> ra_serf always starts an RA session with an OPTIONS request against
> - the repository root URI. If new protocol isn't present (or an
> + the repository root URI. If new protocol isn't present (or is an
> unsuitable version), it falls back to DeltaV protocol.
>
> TODO: like svnserve, mod_svn may also want to advertise specific
> @@ -175,78 +180,150 @@ DESIGN
> ## TODO: flesh out examples here
>
>
> -4. Commands
> +4. Requests
> -----------
>
> -In the list of commands, all commands are assumed to be attached as
> -?cmd=command to the request URI. Command parameters are all
> -query-encoded (&parm=val), and optional parameters are listed in
> -square brackets. Server response values are assumed to be in response
> -bodies.
> +The following request types generally correspond to the routines
> +svn_ra.h API; where they diverge, they do so in order to improve
> +performance, cacheability, or pipelining potential.
>
> +According to proper HTTP specs, GET requests do not contain request
> +bodies; if a request needs a body, we use POST instead.
>
> - get-latest-rev
>
> - GET /repos[/path]?cmd=get-latest-rev
> + * get-latest-rev
> +
> + GET /repos[/path]/|get-latest-rev
I like the idea of the '/' at the end as it removes the namespace
polution, but this needs a simple fixup when the repository is hosted
on the server root. (Which is supported, but not always stable in mod
dav)
GET /|get-latest-rev would specify the file '|get-latest-rev'
I think using GET //|get-latest-rev for the the repository root case
would fix this. (Note the double / ).
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-20 15:14:31 CEST