Jon Bendtsen wrote:
> I believe that you want to add a proxy to speed up SVN requests, or
> support more users. I especially get this from your sentense:
>
> "A typical use case would be to set up the proxy server on a gateway
> between a lan and the internet, to forward client operations to many
> different real servers on the lan. In other words, a classic proxy
> setup."
Right, sorry about that. That also wasn't as clear as it could have
been. I was thinking of *my* "classic" proxy setup, which is actually a
*reverse* proxy, sitting on port 80 of my public web server and relaying
certain requests on to other lan-based web servers with no internet
connectivity.
So, if we want to compare svnproxy and this design to the HTTP world, it
would actually be a non-caching reverse proxy setup. Does that clarify
things a little?
> I believe that your text misses some text about why a normal regular
> HTTP proxy can not do what you want to achive, or how your solution
> is better.
Given the clarification I made above, this answers itself: a reverse
HTTP proxy could do what I propose, for the http:// and such repository
access methods, provided that the proxy also relays non-HTTP requests
(DAV/DeltaV). This is already possible (I believe) by setting up a
properly configured Apache web server, no extra design or implementation
needed.
As for the svn protocol, it is an inhouse, stateful protocol, which is
not spoken by HTTP proxies and would be (in my opinion) difficult to
translate into something a HTTP proxy would be okay to relay. It would
also require adding a translation layer to translate the HTTP-savvy
dialect back into stateful svn:// for the server on the remote side to
understand what the client is talking about. Fairly complex.
Hence we need new logic and new server software to add reverse proxy
capability to svn:// .
> Now, the reason that i wrote you directly and not to the list is because
> i only just subscribed the other day, so who am i to give judgement,
I had actually replied back to the list because I thought it was a
mistake: I sometimes click "reply", which replies to just the post
author, when I mean to "reply to all". So I quickly corrected this in
my reply. Sorry if reposting your private mail sounded rude, it was not
intended to look like that.
Now, as for "who am I to give judgement": You are someone subscribed to
dev@, and are therefore perfectly and completely free and entitled to
ask questions, comment, shoot down, or otherwise react about whatever
goes on! Please, be my guest. There are no stupid questions, and I'm
quite prepared to explain things if I refer to parts of the Subversion
internals you are not familiar with.
In any case, I value anyone's input on this list at the same level;
nobody gets flamed for "newbieness" or Zark knows what else :-).
So, please, make your concerns and comments public, it can only benefit
us all.
> however, i still believe that at least writting something in your text
> about regular HTTP proxies, would benefit your text.
Given this mail's clarification (that my proposal is actually for what
the HTTP world calls a non-caching reverse proxy, and that normal HTTP
proxy software can't speak the SVN protocol), I'll:
- Add an ASSUMPTIONS section clarifying that I am talking about the
svn:// side only, and
- Add that for the http:// (mod_dav_svn) methods, a regular
non-caching reverse HTTP proxy that is configured to relay DAV/DeltaV
chat should (can a dav_svn guru get back to us on this?) accomplish what
I am proposing, except for the "dynamic reconfiguration" bit which is an
implementation detail for the svn:// proxy server software I'm
proposing.
Would that be okay?
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 24 15:10:53 2005