On Thu, Apr 18, 2002 at 11:38:44AM -0400, William Uther wrote:
> Was wandering home in an inebriated haze last night thinking about this...
Well, I was sober, but I still had many of the same ideas.
> People have been talking about ra_pipe. Someone mentioned putting a
> wrapper around the xml parts of svn to make it. Someone else mentioned they
> thought this would be pretty easy, but there were a few details to work out.
> BUT, doesn't svn already have a pipe protocol - it's called http/webdav. We
> want to replace the transport layer, not the protocol layer.
> I don't know apache/neon that well. Does the following make any sense?
> I believe Apache can be run using inetd (although it is deprecated?). See
> <http://httpd.apache.org/docs/mod/core.html#servertype>. This will be our
> version of the cvs server.
The "please don't make me install apache-2.0 in order to use svn" request
seems reasonable enough to me. If that's the case, apache is right out,
run as-if-from-inetd or not. But does that mean *any* harness for mod_dav_svn
would be unacceptable? I'm not sure. It might not be *too* hard to slap
together a minimal harness for mod_dav_svn, for those that refuse to install
> Then you need to modify neon to create an ne_session from an already open
Or modify neon to be able to create the connection via a callback mechanism,
instead of through socket()/connect(). I'm not sure this is an option,
and if it isn't, this approach would require an overhaul to ra_dav to
use neon via an abstraction.
> Finally, you define a new URI type:
> pipe:/rsh-cmd:user,password/host/rest/of/path/. When you get one of these
Because of the need for very rich syntax, and because of the frailty of
the URL validators, I've been thinking:
Where "pipe-name" is looked up in the user's config to map to the relevant
stuff, of which there could be quite a bit, for certain pipe technologies.
One thing that is necessary is the actual repos-URL to use on the remote
side of the house.
> you use the supplied rsh-cmd and auth info to start up apache on the remote
> host in the same way inetd used to. This gives you a connection to apache
> over ssh. You make a new ne_session from your socket and the path in the
As it stands ra_dav likes to open two sessions. This might be a lose
once you start talking about two SSHs and two mod_dav_svn harnesses.
I'm not sure what it uses those two sessions for, but it might need
to be turned off.
> You now have a secure http connection to the remote machine. ssh is the
> only aperture - this is not the same as running your own instance of apache
> on an unprivileged port. You do what ra_dav currently does over the http
> connection using the ne_session.
Yes, but you are still running apache, and you've gone and modified ra_dav
> It is kinda ugly. It relies upon deprecated features in apache. It
I'm not sure that feature is so much deprecated as discouraged because of
apache's startup overhead. I could easily be wrong about that, though.
> assumes that svn can use "keep alive" stuff to do the entire transation over
> one ne_session. It doesn't require defining a new wire protocol.
AFAICT, svn already uses keep-alive, but it also uses more than one
session, as mentioned above. You're right that we wouldn't need a new
wire protocol, and that might be a big enough win to argue that the
changes to neon and/or ra_dav in order to take this approach would
be worth it.
Because of the "Hippocratic Principle" mentioned in HACKING, I had
planned on going ahead and implementing a new wire protocol. They're
really not that hard, and this one is simple. Or would be simple, if
not for the callbacks *shudder* :-).
It does seem rather inelegant to have two protocols when
really what is needed is transport abstraction, though.
What do you think?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Apr 18 18:34:38 2002