Re: svn commit: r19258 - in branches/svnserve-ssl/subversion: include libsvn_subr

[Greg Hudson <gh...@MIT.EDU>]

On Sat, 2006-04-08 at 07:10 -0700, mbk@tigris.org wrote:
> Add ioctl support to the svn_stream interface.

I hope I am only the first to say: ick.

If you want to extend an svn stream, why do you need to muck with the
svn_stream interface?  Just create some other functions which operate on
the same object as the stream's baton.


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

Re: svn commit: r19258 - in branches/svnserve-ssl/subversion: include libsvn_subr

[Greg Hudson <gh...@MIT.EDU>]

On Sat, 2006-04-08 at 18:15 -0400, mark benedetto king wrote:
> I wish svn_stream were already extensible.  It wasn't.

The stream type exists to provide a very specific set of polymorphic
operations, not to be a generic object interface.

> I don't see how to create some other functions which operate on the
> stream's baton, because I don't see how to get the stream to cough
> up its baton.

You control the code which creates the stream.  Store the baton (or the
relevant part of the baton, if that's more convenient) somewhere.

> I really do think this is better than making a clone of the svn_stream
> implementation inside of libsvn_ra_svn, which is the next-easiest
> way that comes to mind.

Even if it turns out that cloning svn_stream in ra_svn is the most
convenient way of doing what I said above, that's still better than
pushing complexity into the deeper layers of the system.  A system's
learning curve becomes steeper as complexity is pushed into the deeper
layers ("oh, we do this thing here because one of the fifteen callers
has this odd requirement...").


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

Re: svn commit: r19258 - in branches/svnserve-ssl/subversion: include libsvn_subr

[mark benedetto king <mb...@lowlatency.com>]

On Sat, Apr 08, 2006 at 08:43:21AM -0700, Justin Erenkrantz wrote:
> On 4/8/06, Greg Hudson <gh...@mit.edu> wrote:
> > I hope I am only the first to say: ick.
> 
> +1.
> 

Greg/Justin:

I wish svn_stream were already extensible.  It wasn't.

> > If you want to extend an svn stream, why do you need to muck with the
> > svn_stream interface?  Just create some other functions which operate on
> > the same object as the stream's baton.
> 

Greg:

The original implementation added "timeout" and "data_pending" callbacks,
to which you (quite reasonably) objected (on the grounds that they were
too specific to a particular use): 

http://svn.haxx.se/dev/archive-2004-11/1211.shtml

This approach does not pollute the stream interface, instead it makes
it more flexible; callers can now arbitrarily extend the new interface.

I don't see how to create some other functions which operate on the
stream's baton, because I don't see how to get the stream to cough
up its baton.  I figured that was by design, otherwise I would have
just added a "get_baton" method and avoided this discussion entirely.

I really do think this is better than making a clone of the svn_stream
implementation inside of libsvn_ra_svn, which is the next-easiest
way that comes to mind.

Is there something I'm missing, or is that what you're suggesting
and we simply disagree?

> Or, just wrap the stream with another stream.  OpenSSL offers buffer
> streams - so SSL should just be implemented as a stream wrapper: like
> Base64, svndiff, etc.  -- justin

Justin:

How is that different from what was in the svnserve-ssl branch before
I rebranched?

--ben


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

Re: svn commit: r19258 - in branches/svnserve-ssl/subversion: include libsvn_subr

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 4/8/06, Greg Hudson <gh...@mit.edu> wrote:
> I hope I am only the first to say: ick.

+1.

> If you want to extend an svn stream, why do you need to muck with the
> svn_stream interface?  Just create some other functions which operate on
> the same object as the stream's baton.

Or, just wrap the stream with another stream.  OpenSSL offers buffer
streams - so SSL should just be implemented as a stream wrapper: like
Base64, svndiff, etc.  -- justin

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