You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2008/09/30 21:22:52 UTC
New HTTP Protocol (was re: svn commit: r33365)
In all seriousness, I really do want to start a design discussion on
the list... but it's much easier to start a discussion when there's a
document for everyone to talk about. That's why I committed the doc
first.
Just as gstein finally stepped up to the plate regarding libsvn_wc --
"enough already, stop the madness", I feel like our continued use of
DeltaV is another madness that needs to be corrected.
Eight years ago, gstein painted a rosy picture of all sorts of DeltaV
clients and servers popping up, and we shared a dream of being at the
forefront of that ecosystem. It turns out that while WebDAV itself
was a success (there's a client built into every OS now), DeltaV never
really caught on. While I think our choice of "apache as server" is
still a huge win in terms of features, we've been paying a continual
price for trying to support DeltaV. Specifically, (1) a huge
performance penalty, and (2) a huge maintenance burden.
If you look at my designdoc, I'm basically suggesting we create a new
HTTP protocol that's entirely specific to subversion. In a nutshell,
it's essentially svnserve's protocol over HTTP. Just as each svn_ra.h
API corresponds to a single svnserve network turnaround, I'm
suggesting we do the same thing over HTTP. For reads, we issue a GET
request; for writes we use a POST request. In both situations, the
exact RA command and parameters embedded directly in the request URI.
For example, this API:
svn_error_t *svn_ra_rev_proplist(ra_session, 23, &props, pool);
Would turn into a request like this:
GET /repos?cmd=rev-proplist&r=23
(Incidentally, this is the way mercurial embeds its own RA API in
HTTP, and it works swimmingly.)
What's the point of doing all this?
1. We get a big speedup. No more crazy turnarounds trying to
'propfind' our way through layers of DeltaV abstractions. Instead, we
can make apache respond nearly as fast as svnserve -- every RA request
is exactly one turnaround. I would expect svnserve and apache to have
the same number of turnarounds, with the same minimal amount of data
per request.
2. We get long-term maintainability. If gstein and I got hit by a
bus, how many people could step in and debug mod_dav_svn right now?
With this new system, we get an HTTP protocol that's just as readable
as svnserve -- one which instantly makes sense to anyone looking at
the network trace, and which is just as easily extended as svnserve.
I know certain folks have put a *lot* of effort into making ra_serf
handle all of the insane edge-cases and quirks of DeltaV -- and I
don't mean to diminish that work. But for the long term, I want to
put my foot down and "stop the madness". If some high-powered admins
out there really need autoversioning, or want to put up a proxy-server
that can handle all serf checkouts under a huge traffic load, or have
transparent write-thru proxying -- then fine, mod_dav_svn can be the
proper tool for that job. It can stick around, along with client
support for 'classic' DeltaV protocol. But for the mainstream users,
teams choosing apache shouldn't have to be jealous of svnserve's speed
and comprehensibility.
My only request is that before jumping in on this discussion, please
spend 3 minutes reading the doc I committed. Among other things, it
explains how I envision interoperability between old/new
clients/servers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: New HTTP Protocol (was re: svn commit: r33365)
Posted by Paul Charlton <te...@byiq.com>.
Ben,
In my experience, what makes a network protocol small and fast is:
1) maximize bytes per request
2) minimize connections per "session"
3) minimize bytes per request [not so critical on Internet (vs LAN) due to
higher end to end latencies]
The existing RA api is easily expressed in WSDL notation, and a lot of dev
tool kits will auto-gen an RPC layer with marshalling which can talk to the
remote WSDL.
-----Original Message-----
From: sussman@gmail.com [mailto:sussman@gmail.com] On Behalf Of Ben
Collins-Sussman
Sent: Wednesday, October 01, 2008 6:43 PM
To: Paul Charlton
Cc: Subversion Developers
Subject: Re: New HTTP Protocol (was re: svn commit: r33365)
No discussion has occurred. However, just having looked up WSDL in
wikipedia, the concept somewhat horrifies me. Can you tell us why
we'd be interested?
The whole point of this exercise is to develop a small, fast protocol
that directly aligns with svn's already-abstracted network API. The
whole reason the existing protocol is a semi-fiasco is because we were
trying to wedge ourselves into an existing committee-designed spec,
for the sake of interoperability. The chances of getting me to
repeat this mistake are vanishingly small. :-)
On Wed, Oct 1, 2008 at 8:06 PM, Paul Charlton <te...@byiq.com> wrote:
> Has any discussion occurred around using a formal WSDL for SVN server
> access? Most developer tool kits for Java, .NET, Adobe Flex, PHP, etc ...
> have direct support for WSDL access.
>
>
> -----Original Message-----
> From: sussman@gmail.com [mailto:sussman@gmail.com] On Behalf Of Ben
> Collins-Sussman
> Sent: Tuesday, September 30, 2008 2:23 PM
> To: Subversion Developers
> Subject: New HTTP Protocol (was re: svn commit: r33365)
>
> In all seriousness, I really do want to start a design discussion on
> the list... but it's much easier to start a discussion when there's a
> document for everyone to talk about. That's why I committed the doc
> first.
>
> Just as gstein finally stepped up to the plate regarding libsvn_wc --
> "enough already, stop the madness", I feel like our continued use of
> DeltaV is another madness that needs to be corrected.
>
> Eight years ago, gstein painted a rosy picture of all sorts of DeltaV
> clients and servers popping up, and we shared a dream of being at the
> forefront of that ecosystem. It turns out that while WebDAV itself
> was a success (there's a client built into every OS now), DeltaV never
> really caught on. While I think our choice of "apache as server" is
> still a huge win in terms of features, we've been paying a continual
> price for trying to support DeltaV. Specifically, (1) a huge
> performance penalty, and (2) a huge maintenance burden.
>
> If you look at my designdoc, I'm basically suggesting we create a new
> HTTP protocol that's entirely specific to subversion. In a nutshell,
> it's essentially svnserve's protocol over HTTP. Just as each svn_ra.h
> API corresponds to a single svnserve network turnaround, I'm
> suggesting we do the same thing over HTTP. For reads, we issue a GET
> request; for writes we use a POST request. In both situations, the
> exact RA command and parameters embedded directly in the request URI.
>
> For example, this API:
>
> svn_error_t *svn_ra_rev_proplist(ra_session, 23, &props, pool);
>
> Would turn into a request like this:
>
> GET /repos?cmd=rev-proplist&r=23
>
> (Incidentally, this is the way mercurial embeds its own RA API in
> HTTP, and it works swimmingly.)
>
> What's the point of doing all this?
>
> 1. We get a big speedup. No more crazy turnarounds trying to
> 'propfind' our way through layers of DeltaV abstractions. Instead, we
> can make apache respond nearly as fast as svnserve -- every RA request
> is exactly one turnaround. I would expect svnserve and apache to have
> the same number of turnarounds, with the same minimal amount of data
> per request.
>
> 2. We get long-term maintainability. If gstein and I got hit by a
> bus, how many people could step in and debug mod_dav_svn right now?
> With this new system, we get an HTTP protocol that's just as readable
> as svnserve -- one which instantly makes sense to anyone looking at
> the network trace, and which is just as easily extended as svnserve.
>
> I know certain folks have put a *lot* of effort into making ra_serf
> handle all of the insane edge-cases and quirks of DeltaV -- and I
> don't mean to diminish that work. But for the long term, I want to
> put my foot down and "stop the madness". If some high-powered admins
> out there really need autoversioning, or want to put up a proxy-server
> that can handle all serf checkouts under a huge traffic load, or have
> transparent write-thru proxying -- then fine, mod_dav_svn can be the
> proper tool for that job. It can stick around, along with client
> support for 'classic' DeltaV protocol. But for the mainstream users,
> teams choosing apache shouldn't have to be jealous of svnserve's speed
> and comprehensibility.
>
> My only request is that before jumping in on this discussion, please
> spend 3 minutes reading the doc I committed. Among other things, it
> explains how I envision interoperability between old/new
> clients/servers.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
No discussion has occurred. However, just having looked up WSDL in
wikipedia, the concept somewhat horrifies me. Can you tell us why
we'd be interested?
The whole point of this exercise is to develop a small, fast protocol
that directly aligns with svn's already-abstracted network API. The
whole reason the existing protocol is a semi-fiasco is because we were
trying to wedge ourselves into an existing committee-designed spec,
for the sake of interoperability. The chances of getting me to
repeat this mistake are vanishingly small. :-)
On Wed, Oct 1, 2008 at 8:06 PM, Paul Charlton <te...@byiq.com> wrote:
> Has any discussion occurred around using a formal WSDL for SVN server
> access? Most developer tool kits for Java, .NET, Adobe Flex, PHP, etc ...
> have direct support for WSDL access.
>
>
> -----Original Message-----
> From: sussman@gmail.com [mailto:sussman@gmail.com] On Behalf Of Ben
> Collins-Sussman
> Sent: Tuesday, September 30, 2008 2:23 PM
> To: Subversion Developers
> Subject: New HTTP Protocol (was re: svn commit: r33365)
>
> In all seriousness, I really do want to start a design discussion on
> the list... but it's much easier to start a discussion when there's a
> document for everyone to talk about. That's why I committed the doc
> first.
>
> Just as gstein finally stepped up to the plate regarding libsvn_wc --
> "enough already, stop the madness", I feel like our continued use of
> DeltaV is another madness that needs to be corrected.
>
> Eight years ago, gstein painted a rosy picture of all sorts of DeltaV
> clients and servers popping up, and we shared a dream of being at the
> forefront of that ecosystem. It turns out that while WebDAV itself
> was a success (there's a client built into every OS now), DeltaV never
> really caught on. While I think our choice of "apache as server" is
> still a huge win in terms of features, we've been paying a continual
> price for trying to support DeltaV. Specifically, (1) a huge
> performance penalty, and (2) a huge maintenance burden.
>
> If you look at my designdoc, I'm basically suggesting we create a new
> HTTP protocol that's entirely specific to subversion. In a nutshell,
> it's essentially svnserve's protocol over HTTP. Just as each svn_ra.h
> API corresponds to a single svnserve network turnaround, I'm
> suggesting we do the same thing over HTTP. For reads, we issue a GET
> request; for writes we use a POST request. In both situations, the
> exact RA command and parameters embedded directly in the request URI.
>
> For example, this API:
>
> svn_error_t *svn_ra_rev_proplist(ra_session, 23, &props, pool);
>
> Would turn into a request like this:
>
> GET /repos?cmd=rev-proplist&r=23
>
> (Incidentally, this is the way mercurial embeds its own RA API in
> HTTP, and it works swimmingly.)
>
> What's the point of doing all this?
>
> 1. We get a big speedup. No more crazy turnarounds trying to
> 'propfind' our way through layers of DeltaV abstractions. Instead, we
> can make apache respond nearly as fast as svnserve -- every RA request
> is exactly one turnaround. I would expect svnserve and apache to have
> the same number of turnarounds, with the same minimal amount of data
> per request.
>
> 2. We get long-term maintainability. If gstein and I got hit by a
> bus, how many people could step in and debug mod_dav_svn right now?
> With this new system, we get an HTTP protocol that's just as readable
> as svnserve -- one which instantly makes sense to anyone looking at
> the network trace, and which is just as easily extended as svnserve.
>
> I know certain folks have put a *lot* of effort into making ra_serf
> handle all of the insane edge-cases and quirks of DeltaV -- and I
> don't mean to diminish that work. But for the long term, I want to
> put my foot down and "stop the madness". If some high-powered admins
> out there really need autoversioning, or want to put up a proxy-server
> that can handle all serf checkouts under a huge traffic load, or have
> transparent write-thru proxying -- then fine, mod_dav_svn can be the
> proper tool for that job. It can stick around, along with client
> support for 'classic' DeltaV protocol. But for the mainstream users,
> teams choosing apache shouldn't have to be jealous of svnserve's speed
> and comprehensibility.
>
> My only request is that before jumping in on this discussion, please
> spend 3 minutes reading the doc I committed. Among other things, it
> explains how I envision interoperability between old/new
> clients/servers.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: New HTTP Protocol (was re: svn commit: r33365)
Posted by Paul Charlton <te...@byiq.com>.
Has any discussion occurred around using a formal WSDL for SVN server
access? Most developer tool kits for Java, .NET, Adobe Flex, PHP, etc ...
have direct support for WSDL access.
-----Original Message-----
From: sussman@gmail.com [mailto:sussman@gmail.com] On Behalf Of Ben
Collins-Sussman
Sent: Tuesday, September 30, 2008 2:23 PM
To: Subversion Developers
Subject: New HTTP Protocol (was re: svn commit: r33365)
In all seriousness, I really do want to start a design discussion on
the list... but it's much easier to start a discussion when there's a
document for everyone to talk about. That's why I committed the doc
first.
Just as gstein finally stepped up to the plate regarding libsvn_wc --
"enough already, stop the madness", I feel like our continued use of
DeltaV is another madness that needs to be corrected.
Eight years ago, gstein painted a rosy picture of all sorts of DeltaV
clients and servers popping up, and we shared a dream of being at the
forefront of that ecosystem. It turns out that while WebDAV itself
was a success (there's a client built into every OS now), DeltaV never
really caught on. While I think our choice of "apache as server" is
still a huge win in terms of features, we've been paying a continual
price for trying to support DeltaV. Specifically, (1) a huge
performance penalty, and (2) a huge maintenance burden.
If you look at my designdoc, I'm basically suggesting we create a new
HTTP protocol that's entirely specific to subversion. In a nutshell,
it's essentially svnserve's protocol over HTTP. Just as each svn_ra.h
API corresponds to a single svnserve network turnaround, I'm
suggesting we do the same thing over HTTP. For reads, we issue a GET
request; for writes we use a POST request. In both situations, the
exact RA command and parameters embedded directly in the request URI.
For example, this API:
svn_error_t *svn_ra_rev_proplist(ra_session, 23, &props, pool);
Would turn into a request like this:
GET /repos?cmd=rev-proplist&r=23
(Incidentally, this is the way mercurial embeds its own RA API in
HTTP, and it works swimmingly.)
What's the point of doing all this?
1. We get a big speedup. No more crazy turnarounds trying to
'propfind' our way through layers of DeltaV abstractions. Instead, we
can make apache respond nearly as fast as svnserve -- every RA request
is exactly one turnaround. I would expect svnserve and apache to have
the same number of turnarounds, with the same minimal amount of data
per request.
2. We get long-term maintainability. If gstein and I got hit by a
bus, how many people could step in and debug mod_dav_svn right now?
With this new system, we get an HTTP protocol that's just as readable
as svnserve -- one which instantly makes sense to anyone looking at
the network trace, and which is just as easily extended as svnserve.
I know certain folks have put a *lot* of effort into making ra_serf
handle all of the insane edge-cases and quirks of DeltaV -- and I
don't mean to diminish that work. But for the long term, I want to
put my foot down and "stop the madness". If some high-powered admins
out there really need autoversioning, or want to put up a proxy-server
that can handle all serf checkouts under a huge traffic load, or have
transparent write-thru proxying -- then fine, mod_dav_svn can be the
proper tool for that job. It can stick around, along with client
support for 'classic' DeltaV protocol. But for the mainstream users,
teams choosing apache shouldn't have to be jealous of svnserve's speed
and comprehensibility.
My only request is that before jumping in on this discussion, please
spend 3 minutes reading the doc I committed. Among other things, it
explains how I envision interoperability between old/new
clients/servers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 2, 2008 at 3:46 AM, Lieven Govaerts <sv...@mobsol.be> wrote:
>> A lot of the extra round-trips with DeltaV come from property-hell -
>> splitting things up into multiple requests is a *good* thing - big,
>> giant API calls are a disaster and should be avoided. Thinking that
>> more 'REPORT' calls is the answer seems like we're going down the
>> wrong path. Fine-grained and quick APIs should be our desire, IMO.
>
> Are you talking about the ra API here? Or about the mod_dav_svn API?
I mean the mod_dav_svn API, but yes, I do expect that if we take a
step back and re-think some of the RA API in conjunction with this, we
can probably find even more speed ups. The more we're willing to put
on the table about rethinking, the more opportunities we'll have for
increasing performance across the board. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Lieven Govaerts <sv...@mobsol.be>.
Justin Erenkrantz wrote:
> On Tue, Sep 30, 2008 at 2:22 PM, Ben Collins-Sussman
> <su...@red-bean.com> wrote:
>> Would turn into a request like this:
>>
>> GET /repos?cmd=rev-proplist&r=23
>
> I'm repeating a bit what Greg already commented in the docs, but yuck.
> This is a *very* ugly way to do this. Plus, you are killing off any
> way of doing caching by using query args. Any solution that we do
> should be very simple and scale with good HTTP proxy caches, IMO.
>
> A lot of the extra round-trips with DeltaV come from property-hell -
> splitting things up into multiple requests is a *good* thing - big,
> giant API calls are a disaster and should be avoided. Thinking that
> more 'REPORT' calls is the answer seems like we're going down the
> wrong path. Fine-grained and quick APIs should be our desire, IMO.
Are you talking about the ra API here? Or about the mod_dav_svn API?
If you want to do decent pipelining you need to make less calls to the
ra API, so that each call can pipeline multiple requests to the server.
Take the example of svnsync. In 1.5, svnsync over ra_serf is three times
as fast as over ra_neon. How? By pipelining the PROPFIND and GET
requests over the same connection. Now in order to be able to do that,
we needed to replace the 'replay' API with 'replay_range', so now
there's only one ra call for all the revisions to sync, instead of rev.
per rev. Obviously replay is very specific and well-suited for this type
of pipelining.
I'm just saying, in order to maximize performance over serf we'll need
to review the ra API too.
..
>
> The one killer feature I want to add to ra_serf is commit
> parallelization - this is something that svnserve can't do (it does
> just a tiny bit of commit pipelining), but I think we can come up with
> a clever way of doing it. And, honestly, DeltaV isn't *too* bad when
> it comes to this, so it's probably already somewhat doable, but
> there's some nasty request dependency issues.
>
That's one thing. But the performance bottlenecks are not always inside
the ra layer. If you look at merge tracking right now, for a reasonable
sized merge, you're looking at the ra layer opening 100's of connections
to the server. Now that's slow on its own, but if you add a Kerberos and
SSL handshake to the connection startup time you get dog slow
performance. Fixing this issue alone will have more impact on
performance than replacing XML with protobuffers.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 2, 2008 at 1:40 AM, Bert Huijben <be...@vmoo.com> wrote:
> Why would using query args kill proxies?
Any requests with query args aren't cachable by default.
(Your response confuses proxies and caches a bit.) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: New HTTP Protocol (was re: svn commit: r33365)
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: justin.erenkrantz@gmail.com [mailto:justin.erenkrantz@gmail.com]
> On Behalf Of Justin Erenkrantz
> Sent: donderdag 2 oktober 2008 9:04
> To: Ben Collins-Sussman
> Cc: Subversion Developers
> Subject: Re: New HTTP Protocol (was re: svn commit: r33365)
>
> On Tue, Sep 30, 2008 at 2:22 PM, Ben Collins-Sussman
> <su...@red-bean.com> wrote:
> > Would turn into a request like this:
> >
> > GET /repos?cmd=rev-proplist&r=23
>
> I'm repeating a bit what Greg already commented in the docs, but yuck.
> This is a *very* ugly way to do this. Plus, you are killing off any
> way of doing caching by using query args. Any solution that we do
> should be very simple and scale with good HTTP proxy caches, IMO.
Why would using query args kill proxies?
Any proxy that follows the HTTP RFCs uses the proxy headers to determine
what should and what shouldn't be cached.
The '?' has nothing to do with that.
I know the proxy I used in the late 1990s did some trickery on query
strings, but any HTTP 1.0/1.1 compliant proxy server doesn't handle query
strings that way.
We should just make sure we try to create the parameters always in the same
order as the ordering of the query parameters /does/ matter for caching.
Bert
> A lot of the extra round-trips with DeltaV come from property-hell -
> splitting things up into multiple requests is a *good* thing - big,
> giant API calls are a disaster and should be avoided. Thinking that
> more 'REPORT' calls is the answer seems like we're going down the
> wrong path. Fine-grained and quick APIs should be our desire, IMO.
> But, the issue with properties is that it introduces a linear, ordered
> dependency between requests - this means that the GET for the data and
> the PROPFIND for the metadata have a relationship. If we could
> somehow better combine that into one request/response cycle, we'd
> simplify a *lot* of code.
>
> Also, using XML as a transport mechanism is just plain lame - as Greg
> said in the protocol docs, switching to protocol buffers or something
> like that would be a *huge* performance win. ra_serf pretty much only
> uses XML for meta-data, but it's still a PITA.
>
> By and large, my experience with ra_serf is that a lot of the
> intrinsic current performance bottlenecks is waiting for disk I/O due
> to crappiness inherent in libsvn_wc. Fixing up libsvn_wc to have a
> much higher throughput should enable us to see where things could be
> improved at the protocol level. So, it'll be a bit chicken and egg
> here with the wc work too.
>
> The one killer feature I want to add to ra_serf is commit
> parallelization - this is something that svnserve can't do (it does
> just a tiny bit of commit pipelining), but I think we can come up with
> a clever way of doing it. And, honestly, DeltaV isn't *too* bad when
> it comes to this, so it's probably already somewhat doable, but
> there's some nasty request dependency issues.
>
> > My only request is that before jumping in on this discussion, please
> > spend 3 minutes reading the doc I committed. Among other things, it
> > explains how I envision interoperability between old/new
> > clients/servers.
>
> Wild-ass suggestion - I know where Greg and I will be between November
> 3 and 7th - *grin* - how about coming down to New Orleans and stopping
> by ApacheCon to go over this? I think a few hours or even a day
> face-to-face would really help here and I think we could walk away
> with a pretty finished protocol stack design. From my ra_serf
> background, I know where the particular pain points are. So, I'd
> really like to be able to contribute here... -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Thu, Oct 2, 2008 at 10:06 AM, <su...@tigris.org> wrote:
> Author: sussman
> Date: Thu Oct 2 08:06:05 2008
> New Revision: 33398
>
> Log:
> notes/http-protocol-v2.txt: huge rewrite, based on discussions.
>
I've hopefully clarified a lot of ideas in this next pass; still not
finished yet.
Greg, it's really kinda awkward to have discussions directly in the
designdoc itself. If you want to comment, can you just reply to the
commit-email and put the comments inline?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Oct 2, 2008 at 3:54 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> On Thu, Oct 2, 2008 at 2:04 AM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> P.S. I did some reading on both protocol buffers and thrift -- and
> neither technology seems to work as a replacement for our XML trees.
> We need to make sure that our big trees (editor-drives) are never held
> entirely in memory at once, either when serializing or deserializing
> them. Both protobufs and thrift insist on holding the whole 'object'
> in memory at once. Urk. Maybe we can just share svnserve's
> parser/unparser for lisp-representations of trees. I'm sure it's
> still way faster than XML.
>
I'm +1 for using svnserver parser/unparser for http protocol v2:
- we already have protocol and implementation for
- svnserve protocol efficiently handles binary data
- svnserve protocol is easy and sufficient
- as Ben noted serialization should be easy adopted to serf_bucket_t
approach where request/response data parsed/unparsed on demand.
--
Ivan Zhakov
VisualSVN Team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Oct 2, 2008 at 10:22 AM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
>...
> No need to fret, I'm trying to incorporate everything into the
> designdoc -- that's where multiple ideas should come to rest and
> ultimately get evaluated. The point of the designdoc is that it gives
> us specific cases to debate about, rather than endlessly hand-waving
> and speaking about a multitude of broad goals. :-)
That's why I recorded comments right in the doc... :-) (kinda like
what we've been doing in wc-ng-design)
Easier for a newcomer to see various points of view, questions, additions, etc.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Thu, Oct 2, 2008 at 12:08 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Oct 2, 2008 at 1:04 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> On Thu, Oct 2, 2008 at 10:01 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> 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 trying to follow the discussion on-list, but I'm just suggesting
>> that face-to-face with interested folks might speed the process up a
>> bit and move it from discussions into prototypes or, *gasp*, even
>> actual code. =) -- justin
>
> I know, what I meant is how can we get the "totality" of these ideas
> on paper? It seems like you have some bigger ideas and wanted to be
> sure they are captured. Maybe some of your comments are just more
> obvious to others than me? :) For example, when you talk about making
> the process take advantage of parallel operations is it obvious to Ben
> what would have to be done to support that?
>
> Also, in the flow of conversation it seems easy to forget what the
> things are we are agreeing to. Especially when you have Ivan
> proposing one idea, and some people agreeing. And you proposing a
> counter idea, and others agreeing.
No need to fret, I'm trying to incorporate everything into the
designdoc -- that's where multiple ideas should come to rest and
ultimately get evaluated. The point of the designdoc is that it gives
us specific cases to debate about, rather than endlessly hand-waving
and speaking about a multitude of broad goals. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Oct 2, 2008 at 1:04 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Thu, Oct 2, 2008 at 10:01 AM, Mark Phippard <ma...@gmail.com> wrote:
>> 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 trying to follow the discussion on-list, but I'm just suggesting
> that face-to-face with interested folks might speed the process up a
> bit and move it from discussions into prototypes or, *gasp*, even
> actual code. =) -- justin
I know, what I meant is how can we get the "totality" of these ideas
on paper? It seems like you have some bigger ideas and wanted to be
sure they are captured. Maybe some of your comments are just more
obvious to others than me? :) For example, when you talk about making
the process take advantage of parallel operations is it obvious to Ben
what would have to be done to support that?
Also, in the flow of conversation it seems easy to forget what the
things are we are agreeing to. Especially when you have Ivan
proposing one idea, and some people agreeing. And you proposing a
counter idea, and others agreeing.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 2, 2008 at 10:01 AM, Mark Phippard <ma...@gmail.com> wrote:
> 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 trying to follow the discussion on-list, but I'm just suggesting
that face-to-face with interested folks might speed the process up a
bit and move it from discussions into prototypes or, *gasp*, even
actual code. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Oct 2, 2008 at 12:36 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> On Thu, Oct 2, 2008 at 10:37 AM, Justin Erenkrantz
> <ju...@erenkrantz.com> wrote:
>> On Thu, Oct 2, 2008 at 4:54 AM, Ben Collins-Sussman
>> <su...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Thu, Oct 2, 2008 at 10:37 AM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Thu, Oct 2, 2008 at 4:54 AM, Ben Collins-Sussman
> <su...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 2, 2008 at 4:54 AM, Ben Collins-Sussman
<su...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Thu, Oct 2, 2008 at 2:04 AM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> Wild-ass suggestion - I know where Greg and I will be between November
> 3 and 7th - *grin* - how about coming down to New Orleans and stopping
> by ApacheCon to go over this?
Justin -- I'm totally aware of the need for (a) cacheability and (b)
allowing pipelining whereever possible. I've been talking with gstein
about this stuff both on this list and in IRC, so I promise I'm not
going to be a religious zealot in terms of mapping RA apis to single
network requests. That's the *general* default pattern, but I think
we'll have lots of exceptions where it makes sense. For example, an
'update' should be requestable either as a single response (with all
filedata), or as a skeletal response, allowing serf to follow up with
pipelined (cacheable) GETs.
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.
But yes, there's actually a chance I may need to be in New Orleans for
a couple of days in early November -- totally unrelated to svn. If
that happens, I'd be thrilled to meet with you guys in person.
Meanwhile, let me keep poking at the designdoc and soliciting
discussion.
P.S. I did some reading on both protocol buffers and thrift -- and
neither technology seems to work as a replacement for our XML trees.
We need to make sure that our big trees (editor-drives) are never held
entirely in memory at once, either when serializing or deserializing
them. Both protobufs and thrift insist on holding the whole 'object'
in memory at once. Urk. Maybe we can just share svnserve's
parser/unparser for lisp-representations of trees. I'm sure it's
still way faster than XML.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 2, 2008 at 12:34 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> Justin, I disagree with you.
>
> I've tested that one small PROPFIND roundtrip costs at least 200ms
> over WAN. PROPFIND requests very simple, so performance slow down
> cannot be from xml stuff.
> When doing simple operations like svn list Subversion perform about 8 PROPFINDs.
Let me be clear: the PROPFINDs I meant were in respect to the getting
the properties for a single file - that is ra_serf has to issue two
requests for every file that it wants to update. (ra_serf does have
optimization logic to know if we update just the text or just the
properties, but really it'd be nice to somehow avert the two requests
and be able to deliver the results atomically.)
That said, the PROPFINDs that we do for repository meta-operations are
kinda pointless and too verbose. But, those aren't the PROPFINDs that
I meant in my initial email.
> I really like idea to make http protocol perform one HTTP request for
> one RA call. Our RA calls simple enough and already well designed, so
> http requests will be simple as our RA calls.
Then, we are back to essentially doing REPORT for everything. I don't
believe that is a very good or scalable HTTP-based protocol. --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Oct 2, 2008 at 11:04 AM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Tue, Sep 30, 2008 at 2:22 PM, Ben Collins-Sussman
> <su...@red-bean.com> wrote:
>> Would turn into a request like this:
>>
>> GET /repos?cmd=rev-proplist&r=23
>
> I'm repeating a bit what Greg already commented in the docs, but yuck.
> This is a *very* ugly way to do this. Plus, you are killing off any
> way of doing caching by using query args. Any solution that we do
> should be very simple and scale with good HTTP proxy caches, IMO.
>
> A lot of the extra round-trips with DeltaV come from property-hell -
> splitting things up into multiple requests is a *good* thing - big,
> giant API calls are a disaster and should be avoided. Thinking that
> more 'REPORT' calls is the answer seems like we're going down the
> wrong path. Fine-grained and quick APIs should be our desire, IMO.
> But, the issue with properties is that it introduces a linear, ordered
> dependency between requests - this means that the GET for the data and
> the PROPFIND for the metadata have a relationship. If we could
> somehow better combine that into one request/response cycle, we'd
> simplify a *lot* of code.
>
> Also, using XML as a transport mechanism is just plain lame - as Greg
> said in the protocol docs, switching to protocol buffers or something
> like that would be a *huge* performance win. ra_serf pretty much only
> uses XML for meta-data, but it's still a PITA.
>
> By and large, my experience with ra_serf is that a lot of the
> intrinsic current performance bottlenecks is waiting for disk I/O due
> to crappiness inherent in libsvn_wc. Fixing up libsvn_wc to have a
> much higher throughput should enable us to see where things could be
> improved at the protocol level. So, it'll be a bit chicken and egg
> here with the wc work too.
>
Justin, I disagree with you.
I've tested that one small PROPFIND roundtrip costs at least 200ms
over WAN. PROPFIND requests very simple, so performance slow down
cannot be from xml stuff.
When doing simple operations like svn list Subversion perform about 8 PROPFINDs.
I really like idea to make http protocol perform one HTTP request for
one RA call. Our RA calls simple enough and already well designed, so
http requests will be simple as our RA calls.
--
Ivan Zhakov
VisualSVN Team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Sep 30, 2008 at 2:22 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> Would turn into a request like this:
>
> GET /repos?cmd=rev-proplist&r=23
I'm repeating a bit what Greg already commented in the docs, but yuck.
This is a *very* ugly way to do this. Plus, you are killing off any
way of doing caching by using query args. Any solution that we do
should be very simple and scale with good HTTP proxy caches, IMO.
A lot of the extra round-trips with DeltaV come from property-hell -
splitting things up into multiple requests is a *good* thing - big,
giant API calls are a disaster and should be avoided. Thinking that
more 'REPORT' calls is the answer seems like we're going down the
wrong path. Fine-grained and quick APIs should be our desire, IMO.
But, the issue with properties is that it introduces a linear, ordered
dependency between requests - this means that the GET for the data and
the PROPFIND for the metadata have a relationship. If we could
somehow better combine that into one request/response cycle, we'd
simplify a *lot* of code.
Also, using XML as a transport mechanism is just plain lame - as Greg
said in the protocol docs, switching to protocol buffers or something
like that would be a *huge* performance win. ra_serf pretty much only
uses XML for meta-data, but it's still a PITA.
By and large, my experience with ra_serf is that a lot of the
intrinsic current performance bottlenecks is waiting for disk I/O due
to crappiness inherent in libsvn_wc. Fixing up libsvn_wc to have a
much higher throughput should enable us to see where things could be
improved at the protocol level. So, it'll be a bit chicken and egg
here with the wc work too.
The one killer feature I want to add to ra_serf is commit
parallelization - this is something that svnserve can't do (it does
just a tiny bit of commit pipelining), but I think we can come up with
a clever way of doing it. And, honestly, DeltaV isn't *too* bad when
it comes to this, so it's probably already somewhat doable, but
there's some nasty request dependency issues.
> My only request is that before jumping in on this discussion, please
> spend 3 minutes reading the doc I committed. Among other things, it
> explains how I envision interoperability between old/new
> clients/servers.
Wild-ass suggestion - I know where Greg and I will be between November
3 and 7th - *grin* - how about coming down to New Orleans and stopping
by ApacheCon to go over this? I think a few hours or even a day
face-to-face would really help here and I think we could walk away
with a pretty finished protocol stack design. From my ra_serf
background, I know where the particular pain points are. So, I'd
really like to be able to contribute here... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Branko Čibej <br...@xbc.nu>.
steven higgan wrote:
>
> Is there a demand for an IIS plugin? I've never heard of one, but
> you're the one hearing from corporate customers.
>
>
> apologies Ben, I hit reply instead of Reply all - smacks forehead !!
>
> being one of those corporate people - the answer to your question is a
> definite yes.
>
> i know Apache is good, but at the end of the day if we can get svn
> going over IIS it would be as its one less piece of infrastructure
> that needs to be looked after.
Well you can always get rid of IIS now and win. :)
/. press
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by steven higgan <st...@gmail.com>.
On Wed, Oct 1, 2008 at 11:50 AM, Ben Collins-Sussman
<su...@red-bean.com>wrote:
> On Tue, Sep 30, 2008 at 5:12 PM, Mark Phippard <ma...@gmail.com> wrote:
> > It seems like if we architected this right, it would not be too hard
> > for someone to create an IIS add-in that also supported this feature.
> > Ideally, the real work would be in a reusable library for the Apache
> > module and maybe even svnserve and an IIS version could be created
> > that used the same library?
>
> Is there a demand for an IIS plugin? I've never heard of one, but
> you're the one hearing from corporate customers.
>
apologies Ben, I hit reply instead of Reply all - smacks forehead !!
being one of those corporate people - the answer to your question is a
definite yes.
i know Apache is good, but at the end of the day if we can get svn going
over IIS it would be as its one less piece of infrastructure that needs to
be looked after.
since your basically making a 'subversion web-service' sending xml over the
wire (im guessing this, i havent read your doc - its on the 'todo' list), I
can already imagine an ocean of clients using it.
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 30, 2008 at 8:09 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> On Tue, Sep 30, 2008 at 6:47 PM, Mark Phippard <ma...@gmail.com> wrote:
>> On Tue, Sep 30, 2008 at 6:50 PM, Ben Collins-Sussman
>> <su...@red-bean.com> wrote:
>>>> A little confused by this last sentence. There are three points
>>>> included in it. Wouldn't the first one be the only one that required
>>>> mod_dav_svn? It seems like this new library could work as well, or
>>>> better with the other two.
>>>
>>> You're right. See the other thread with comments from gstein -- he's
>>> pushing for cacheability as a feature, and there's no reason a
>>> well-designed new protocol couldn't be designed for that (or write
>>> proxying).
>>
>> An advantage to the current ra_serf "GET-based" design, besides
>> caching, is access logging. It is very easy to see how often specific
>> resources are being accessed. Current REPORT-based operations mask
>> this. We had one customer (perhaps it will only ever be one) that
>> wanted this.
>
> I think this indicates that the logging should be pushed down into the
> fs layer, rather than living solely at the server-level.
>
> When somebody implements detailed logging for svnserve (inevitably),
> they're going to run into the same problem, and I'm pretty sure
> they're not going to redesign the protocol to make lots of little
> cacheable fetches, rather than single streaming responses.
There is logging for svnserve in trunk. To my knowledge it is the
same sort of operational logging that we have in Apache. But your
point is fair nonetheless.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Tue, Sep 30, 2008 at 6:47 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Sep 30, 2008 at 6:50 PM, Ben Collins-Sussman
> <su...@red-bean.com> wrote:
>>> A little confused by this last sentence. There are three points
>>> included in it. Wouldn't the first one be the only one that required
>>> mod_dav_svn? It seems like this new library could work as well, or
>>> better with the other two.
>>
>> You're right. See the other thread with comments from gstein -- he's
>> pushing for cacheability as a feature, and there's no reason a
>> well-designed new protocol couldn't be designed for that (or write
>> proxying).
>
> An advantage to the current ra_serf "GET-based" design, besides
> caching, is access logging. It is very easy to see how often specific
> resources are being accessed. Current REPORT-based operations mask
> this. We had one customer (perhaps it will only ever be one) that
> wanted this.
I think this indicates that the logging should be pushed down into the
fs layer, rather than living solely at the server-level.
When somebody implements detailed logging for svnserve (inevitably),
they're going to run into the same problem, and I'm pretty sure
they're not going to redesign the protocol to make lots of little
cacheable fetches, rather than single streaming responses.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 30, 2008 at 6:50 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
>> A little confused by this last sentence. There are three points
>> included in it. Wouldn't the first one be the only one that required
>> mod_dav_svn? It seems like this new library could work as well, or
>> better with the other two.
>
> You're right. See the other thread with comments from gstein -- he's
> pushing for cacheability as a feature, and there's no reason a
> well-designed new protocol couldn't be designed for that (or write
> proxying).
An advantage to the current ra_serf "GET-based" design, besides
caching, is access logging. It is very easy to see how often specific
resources are being accessed. Current REPORT-based operations mask
this. We had one customer (perhaps it will only ever be one) that
wanted this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 30, 2008 at 6:50 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
>> It seems like if we architected this right, it would not be too hard
>> for someone to create an IIS add-in that also supported this feature.
>> Ideally, the real work would be in a reusable library for the Apache
>> module and maybe even svnserve and an IIS version could be created
>> that used the same library?
>
> Is there a demand for an IIS plugin? I've never heard of one, but
> you're the one hearing from corporate customers.
I've only heard this on the users@ list a few times. I do not think
it would be something we would want to actively do, but it might be
something we could let the community no is ripe for the doing. I
think there are some Windows shops that would really like it and it
would allow you to use Windows login much more easily.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Tue, Sep 30, 2008 at 5:12 PM, Mark Phippard <ma...@gmail.com> wrote:
>> 2. We get long-term maintainability. If gstein and I got hit by a
>> bus, how many people could step in and debug mod_dav_svn right now?
>> With this new system, we get an HTTP protocol that's just as readable
>> as svnserve -- one which instantly makes sense to anyone looking at
>> the network trace, and which is just as easily extended as svnserve.
>
> Is there possibility of making a common library that they both can use
> for most of the heavy lifting?
Yes, maybe... I alluded to this possibility in the designdoc. For
example, perhaps the code which parses (and unparses) svnserve's
"editor drive" s-expressions could be shared.
>> I know certain folks have put a *lot* of effort into making ra_serf
>> handle all of the insane edge-cases and quirks of DeltaV -- and I
>> don't mean to diminish that work. But for the long term, I want to
>> put my foot down and "stop the madness". If some high-powered admins
>> out there really need autoversioning, or want to put up a proxy-server
>> that can handle all serf checkouts under a huge traffic load, or have
>> transparent write-thru proxying -- then fine, mod_dav_svn can be the
>> proper tool for that job.
>
> A little confused by this last sentence. There are three points
> included in it. Wouldn't the first one be the only one that required
> mod_dav_svn? It seems like this new library could work as well, or
> better with the other two.
You're right. See the other thread with comments from gstein -- he's
pushing for cacheability as a feature, and there's no reason a
well-designed new protocol couldn't be designed for that (or write
proxying).
> Hey, couldn't we ditch wc-props too?
Yes, that's a DeltaV artifact -- basically a client-side cache of a
URL that represents a (rev, path) object. In DeltaV, a client isn't
allowed to construct such a URL -- it has to do a bunch of turnarounds
to 'discover' it, and hence the cache. In a well-designed protocol,
we could just make up a fixed URL syntax and have client and server
agree ahead of time.
(Note, though, that we could still do this right now, even in
mod_dav_svn. We could decide right now on a fixed syntax for a
(rev,path) object, advertise it to the universe, let clients depend on
it -- it just wouldn't be related to DeltaV.)
one of the useless DeltaV
> It seems like if we architected this right, it would not be too hard
> for someone to create an IIS add-in that also supported this feature.
> Ideally, the real work would be in a reusable library for the Apache
> module and maybe even svnserve and an IIS version could be created
> that used the same library?
Is there a demand for an IIS plugin? I've never heard of one, but
you're the one hearing from corporate customers.
But sure, the shared library you're imagining is just a heartbeat away
from a "librarized" svnserve. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Oct 1, 2008 at 7:31 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Ben Collins-Sussman wrote:
>> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>> Mark Phippard wrote:
>>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>>> do this too though. As I said, I think this is a great idea and even
>>>> overdue.
>>> wc-props are optional -- we could ditch them today.
>>
>> ...at the cost of making ra_neon even slower. :-)
>
> Not if we simply dispense with this nonsense of treating the !svn URLs as
> opaque and mysterious.
Note that there are some nice things about the opacity. Given that
you're using a stateless protocol like HTTP to implement a stateful
protocol, it can be convenient to make commits have session affinity;
there's a pretty easy way to hack mod_dav_svn right now to include an
extra token in the URL which your load-balance could use to make
commits have session affinity. (I think we've considered doing this
for code.google but haven't.)
Of course, this is only necessary because the current protocol
implements an atomic commit as a series of independent HTTP requests,
which would hopefully be avoided by a new protocol.
--dave
> And another easy-win speedup would be for our DAV clients to stop using 12
> PROPFINDS to do simple URL negotation -- we could have long ago written a
> custom REPORT to answer those kinds of questions in a single turnaround.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Wed, Oct 1, 2008 at 9:57 AM, Mark Phippard <ma...@gmail.com> wrote:
> 1) Eliminate the need for 2 URL's. This is bad. With your Google
> code hosting do you really want to offer 2 URL's for all repositories?
> I am sure we do not want to do that at CollabNet and I doubt
> SourceForge and other sites want to either.
>
> 2) We do not have do a new implementation of DAV autoversioning.
Hm, maybe you're right. Even though it will make mod_dav_svn much
more complicated, perhaps it's worth the benefit of having only one
module, and having both protocols available at the same URL. As
discussed in the other thread, it would be really awkward to export
two different URLs for two different protocols.
Let me ponder this a bit, and see if I can evolve the designdoc such
that it assumes that it's building on top our existing mod_dav_svn
structure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 1, 2008 at 10:53 AM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> On Wed, Oct 1, 2008 at 9:37 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Wed, Oct 1, 2008 at 10:31 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> Ben Collins-Sussman wrote:
>>>> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>>>> Mark Phippard wrote:
>>>>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>>>>> do this too though. As I said, I think this is a great idea and even
>>>>>> overdue.
>>>>> wc-props are optional -- we could ditch them today.
>>>>
>>>> ...at the cost of making ra_neon even slower. :-)
>>>
>>> Not if we simply dispense with this nonsense of treating the !svn URLs as
>>> opaque and mysterious.
>>>
>>> And another easy-win speedup would be for our DAV clients to stop using 12
>>> PROPFINDS to do simple URL negotation -- we could have long ago written a
>>> custom REPORT to answer those kinds of questions in a single turnaround.
>>
>> Do we even need to do this URL negotiation? Couldn't we just switch
>> to making assumptions about the URL's and dispense with all of this?
>>
>> If we have to continue to maintain mod_dav_svn anyway for older client
>> support, would it make sense to just add new features into current
>> library? Such as custom REPORT requests etc? Does the fact that the
>> current library is related to DAV block us from doing any of the
>> things you want to do?
>
> Is it theoretically possible to move in this direction? Sure.
> mod_dav_svn is currently a strange mix of baroque DeltaV formalities
> and custom svn REPORT requests. We could just 'evolve' mod_dav_svn to
> drop more and more of the DeltaV formalities, until it basically
> becomes nothing but a big heap of custom REPORT exchanges. But I
> argue that this will make mod_dav_svn even harder to read and
> maintain. While ra_neon / ra_serf might be able to simplify their
> chattiness, mod_dav_svn just keeps growing in complexity, getting more
> and more special cases heaped on, and still all going through
> mod_dav's vision of the universe. It contradicts the goal of making
> an HTTP layer which is easily readable and maintainable.
Agreed. But mod_dav_svn is not going away. Maybe we do not add new
features to it, but we have to maintain it. So the code has to live
on and cannot really even be cleaned up. Does putting new code in a
new library make that much difference? Can't the new code just live
in new .c files and be built into the same library for deployment? I
have two goals in suggesting this option:
1) Eliminate the need for 2 URL's. This is bad. With your Google
code hosting do you really want to offer 2 URL's for all repositories?
I am sure we do not want to do that at CollabNet and I doubt
SourceForge and other sites want to either.
2) We do not have do a new implementation of DAV autoversioning.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Wed, Oct 1, 2008 at 9:37 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Oct 1, 2008 at 10:31 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Ben Collins-Sussman wrote:
>>> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>>> Mark Phippard wrote:
>>>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>>>> do this too though. As I said, I think this is a great idea and even
>>>>> overdue.
>>>> wc-props are optional -- we could ditch them today.
>>>
>>> ...at the cost of making ra_neon even slower. :-)
>>
>> Not if we simply dispense with this nonsense of treating the !svn URLs as
>> opaque and mysterious.
>>
>> And another easy-win speedup would be for our DAV clients to stop using 12
>> PROPFINDS to do simple URL negotation -- we could have long ago written a
>> custom REPORT to answer those kinds of questions in a single turnaround.
>
> Do we even need to do this URL negotiation? Couldn't we just switch
> to making assumptions about the URL's and dispense with all of this?
>
> If we have to continue to maintain mod_dav_svn anyway for older client
> support, would it make sense to just add new features into current
> library? Such as custom REPORT requests etc? Does the fact that the
> current library is related to DAV block us from doing any of the
> things you want to do?
Is it theoretically possible to move in this direction? Sure.
mod_dav_svn is currently a strange mix of baroque DeltaV formalities
and custom svn REPORT requests. We could just 'evolve' mod_dav_svn to
drop more and more of the DeltaV formalities, until it basically
becomes nothing but a big heap of custom REPORT exchanges. But I
argue that this will make mod_dav_svn even harder to read and
maintain. While ra_neon / ra_serf might be able to simplify their
chattiness, mod_dav_svn just keeps growing in complexity, getting more
and more special cases heaped on, and still all going through
mod_dav's vision of the universe. It contradicts the goal of making
an HTTP layer which is easily readable and maintainable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 1, 2008 at 10:31 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Ben Collins-Sussman wrote:
>> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>> Mark Phippard wrote:
>>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>>> do this too though. As I said, I think this is a great idea and even
>>>> overdue.
>>> wc-props are optional -- we could ditch them today.
>>
>> ...at the cost of making ra_neon even slower. :-)
>
> Not if we simply dispense with this nonsense of treating the !svn URLs as
> opaque and mysterious.
>
> And another easy-win speedup would be for our DAV clients to stop using 12
> PROPFINDS to do simple URL negotation -- we could have long ago written a
> custom REPORT to answer those kinds of questions in a single turnaround.
Do we even need to do this URL negotiation? Couldn't we just switch
to making assumptions about the URL's and dispense with all of this?
If we have to continue to maintain mod_dav_svn anyway for older client
support, would it make sense to just add new features into current
library? Such as custom REPORT requests etc? Does the fact that the
current library is related to DAV block us from doing any of the
things you want to do?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Julian Reschke <ju...@gmx.de>.
C. Michael Pilato wrote:
> Ben Collins-Sussman wrote:
>> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>> Mark Phippard wrote:
>>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>>> do this too though. As I said, I think this is a great idea and even
>>>> overdue.
>>> wc-props are optional -- we could ditch them today.
>> ...at the cost of making ra_neon even slower. :-)
>
> Not if we simply dispense with this nonsense of treating the !svn URLs as
> opaque and mysterious.
Yes. Using DeltaV discovery of URLs is only required if the client is
supposed to work with other servers, or if you plan to change URL syntax
later on.
> And another easy-win speedup would be for our DAV clients to stop using 12
> PROPFINDS to do simple URL negotation -- we could have long ago written a
> custom REPORT to answer those kinds of questions in a single turnaround.
It would be interesting to see what exactly these requests are, and
whether they could be optimized anyway.
BR, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> Mark Phippard wrote:
>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>> do this too though. As I said, I think this is a great idea and even
>>> overdue.
>> wc-props are optional -- we could ditch them today.
>
> ...at the cost of making ra_neon even slower. :-)
Not if we simply dispense with this nonsense of treating the !svn URLs as
opaque and mysterious.
And another easy-win speedup would be for our DAV clients to stop using 12
PROPFINDS to do simple URL negotation -- we could have long ago written a
custom REPORT to answer those kinds of questions in a single turnaround.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>> do this too though. As I said, I think this is a great idea and even
>> overdue.
>
> wc-props are optional -- we could ditch them today.
...at the cost of making ra_neon even slower. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
> do this too though. As I said, I think this is a great idea and even
> overdue.
wc-props are optional -- we could ditch them today.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: New HTTP Protocol (was re: svn commit: r33365)
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 30, 2008 at 5:22 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> In all seriousness, I really do want to start a design discussion on
> the list... but it's much easier to start a discussion when there's a
> document for everyone to talk about. That's why I committed the doc
> first.
>
> Just as gstein finally stepped up to the plate regarding libsvn_wc --
> "enough already, stop the madness", I feel like our continued use of
> DeltaV is another madness that needs to be corrected.
>
> Eight years ago, gstein painted a rosy picture of all sorts of DeltaV
> clients and servers popping up, and we shared a dream of being at the
> forefront of that ecosystem. It turns out that while WebDAV itself
> was a success (there's a client built into every OS now), DeltaV never
> really caught on. While I think our choice of "apache as server" is
> still a huge win in terms of features, we've been paying a continual
> price for trying to support DeltaV. Specifically, (1) a huge
> performance penalty, and (2) a huge maintenance burden.
>
> If you look at my designdoc, I'm basically suggesting we create a new
> HTTP protocol that's entirely specific to subversion. In a nutshell,
> it's essentially svnserve's protocol over HTTP. Just as each svn_ra.h
> API corresponds to a single svnserve network turnaround, I'm
> suggesting we do the same thing over HTTP. For reads, we issue a GET
> request; for writes we use a POST request. In both situations, the
> exact RA command and parameters embedded directly in the request URI.
>
> For example, this API:
>
> svn_error_t *svn_ra_rev_proplist(ra_session, 23, &props, pool);
>
> Would turn into a request like this:
>
> GET /repos?cmd=rev-proplist&r=23
>
> (Incidentally, this is the way mercurial embeds its own RA API in
> HTTP, and it works swimmingly.)
>
> What's the point of doing all this?
>
> 1. We get a big speedup. No more crazy turnarounds trying to
> 'propfind' our way through layers of DeltaV abstractions. Instead, we
> can make apache respond nearly as fast as svnserve -- every RA request
> is exactly one turnaround. I would expect svnserve and apache to have
> the same number of turnarounds, with the same minimal amount of data
> per request.
This sounds pretty great to me.
> 2. We get long-term maintainability. If gstein and I got hit by a
> bus, how many people could step in and debug mod_dav_svn right now?
> With this new system, we get an HTTP protocol that's just as readable
> as svnserve -- one which instantly makes sense to anyone looking at
> the network trace, and which is just as easily extended as svnserve.
Is there possibility of making a common library that they both can use
for most of the heavy lifting?
> I know certain folks have put a *lot* of effort into making ra_serf
> handle all of the insane edge-cases and quirks of DeltaV -- and I
> don't mean to diminish that work. But for the long term, I want to
> put my foot down and "stop the madness". If some high-powered admins
> out there really need autoversioning, or want to put up a proxy-server
> that can handle all serf checkouts under a huge traffic load, or have
> transparent write-thru proxying -- then fine, mod_dav_svn can be the
> proper tool for that job.
A little confused by this last sentence. There are three points
included in it. Wouldn't the first one be the only one that required
mod_dav_svn? It seems like this new library could work as well, or
better with the other two.
> It can stick around, along with client
> support for 'classic' DeltaV protocol. But for the mainstream users,
> teams choosing apache shouldn't have to be jealous of svnserve's speed
> and comprehensibility.
>
> My only request is that before jumping in on this discussion, please
> spend 3 minutes reading the doc I committed. Among other things, it
> explains how I envision interoperability between old/new
> clients/servers.
Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
do this too though. As I said, I think this is a great idea and even
overdue.
It seems like if we architected this right, it would not be too hard
for someone to create an IIS add-in that also supported this feature.
Ideally, the real work would be in a reusable library for the Apache
module and maybe even svnserve and an IIS version could be created
that used the same library?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org