On Thu, Oct 2, 2008 at 12:36 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Thu, Oct 2, 2008 at 10:37 AM, Justin Erenkrantz
> <justin_at_erenkrantz.com> wrote:
>> On Thu, Oct 2, 2008 at 4:54 AM, Ben Collins-Sussman
>> <sussman_at_red-bean.com> wrote:
>>> Also, I agree that if speed were the *only* issue, we could start
>>> making a bunch of hacks to the existing protocol to get 'most' of the
>>> speedup we want -- make the client start constructing URIs by itself
>>> to eliminate turnarounds, stop using xml, etc. But a large goal here
>>> is to also make things more readable and maintainable for people who
>>> have never seen our HTTP layer before -- it should be as blindingly
>>> obvious as the svnserve protocol, not something steeped in DeltaV
>>> concepts.
>>
>> My concern with using the svnserve protocol as a guide (as seems to be
>> the desire) is that it isn't easily broken down and multiplexed over
>> many connections. Our custom svnserve protocol is really intended to
>> be serviced over a single long-running persistent connection - with
>> most of the logic done server-side - my concern is that an ideal
>> HTTP-based protocol should do the exact opposite. Once we consider
>> latency (which we know is very critical for our use case), we probably
>> want to do as much computation on the client-side and not on the
>> server-side: keep the server as dumb (and efficient) as possible. I
>> believe that this has an impact on the best end protocol for our
>> uses...
>>
>> HTTP servers are very good at parallelization. (If you look at Sun's
>> UltraSparc T1 aka Niagara2 CPUs, the individual CPUs are rather slow,
>> but there are lots of them. This is the direction a lot of web server
>> farms are moving to - lots of cheap but slower CPUs.) Also, with
>> things like repository mirroring being more available, I think
>> higher-end commodity sites - and not just Google Code Hosting - will
>> start to have load-balanced replicated read servers. svn.apache.org
>> already uses mirrors to give us geographic balancing. In a few years,
>> it should be more common to have a cluster of SVN servers per
>> geographic site. -- justin
>>
>
> Fair enough. Let me start with a naive design of "one request per RA
> API", and then we can start going over the requests one-by-one and
> push them towards more pipelining and client-side-smarts. I agree
> with these goals. Let me get all the RA APIs into the designdoc
> first.
So is there something short of Ben going to New Orleans for a "brain
dump" to get Justin's ideas on paper? It seems like Ben's basic idea
is definitely saying "everything is on the table", so why not try to
squeeze as much out of this as we can?
I am sure there are some constraints though ... the editor API? We
probably ought to agree what is "not on the table" too.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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-02 19:01:45 CEST