What's up with ra_pipe?

[Nuutti Kotivuori <na...@iki.fi>]

Hey, what's up with ra_pipe these days? Has anyone done anything to it
recently?

Apparently nobody has touched it in the repository since revision 2000
or so.

This is something I'd personally very much want to see work, but I'm
afraid my expertise and time available will not probably allow me to
tackle it on, atleast not alone.

Were there any decisions made on how to make the implementation?

-- Naked


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: What's up with ra_pipe?

[Karl Fogel <kf...@newton.ch.collab.net>]

mark benedetto king <bk...@inquira.com> writes:
> > This is something I'd personally very much want to see work, but I'm
> > afraid my expertise and time available will not probably allow me to
> > tackle it on, atleast not alone.
> 
> I can share my "svn diff" with you off-list, if you'd like.

No need for it to be off-list, unless you particularly want it to be
private...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: What's up with ra_pipe?

[mark benedetto king <bk...@inquira.com>]

On Tue, Aug 13, 2002 at 06:51:42PM +0300, Nuutti Kotivuori wrote:
> Hey, what's up with ra_pipe these days? Has anyone done anything to it
> recently?
> 

I have been working on it on and off for quite some time.  Mainly off,
though.

> Apparently nobody has touched it in the repository since revision 2000
> or so.
> 

I don't have commit access.

> This is something I'd personally very much want to see work, but I'm
> afraid my expertise and time available will not probably allow me to
> tackle it on, atleast not alone.

I can share my "svn diff" with you off-list, if you'd like.

> 
> Were there any decisions made on how to make the implementation?
> 

Well, the approach that I taken is to build an ra-layer shim; for
every function FOO in the ra vtable, it exposes FOO, packages
FOO's parameters up and sends them down the wire to the remote
service, which reads them, calls ra_local or ra_dav's foo(), and
then packages up the results, sends them back down the wire to
the client, which unpackages them and returns them.

This is the typical "client stub/server stub" RPC model.
One of the principal drawbacks to this model is that callbacks
are a hassle, and of course, we've got them.

The interface is also fairly wide (the commit editors are
what I'm currently bogged down in).

--ben


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org