Re: HTTP protocol v2: single commit request, or many PUTs?

On Mon, Nov 10, 2008 at 9:36 AM, Greg Stein <gstein_at_gmail.com> wrote:
> There ARE NO "turnarounds". You just pipeline a bunch of PUTs up
> there. For all intents and purposes, it *looks* like one big mother
> request.

Sorry, I meant "fewer network requests", not "fewer turnarounds". As
you say, a 'turnaround' implies sending and waiting.

>
> Don't forget that a commit also has COPY and DELETE operations going
> on, too. And in the future, maybe a MOVE or two :-)
>
> IMO, it is easier to understand if you keep the operations separate
> rather than glom them all into one bigass request. Those big glommed
> requests then need to be parsed to be broken up. They also don't
> restart very well in the face of network failure, packet drops, or
> connection closures.
>

Good point, your last one.

Another advantage of a single request is that it means we can use the
'standard' commit editor that the other layers use, and give us more
consistent semantics. (I think this was glasser's request).

Let me revise the lists, leaving out the parallel PUTs, since we have
no plans for that anytime soon.

Multi-request motivations:

  * opens the door for pipelined writes, the way ra_svn does it
  * more resilient on a flaky network
  * more detailed logging
  * don't need to change much code

Single-request motivations:

  * one request means less traffic overall
  * can use standard libsvn_repos commit-editor

Hmmm. Maybe multi-request *is* more advantageous. Let's let this
thread sit around for 24 hours and see if people raise other points.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-10 16:53:20 CET