Greg Hudson <ghudson@MIT.EDU> writes:
> I may have chosen a bad part of the message to quote. My impression is
> that you want to add a new RA method and/or protocol request which takes
> a subcommand, a subcommand-specific set of inputs, and a
> subcommand-specific set of outputs. I don't see how that's better than
> just adding new vtable methods.
It's hard to bunch multiple requests into one network turnaround if we
have a separate vtable method for each request. Of course, it would
be equally hard with the generic RA method described above.
So now I'm looking for a way to do multiple such requests in one
turnaround. That would still be a single RA method, but it might
return N callbacks: it starts the request, then you call whichever of
the callbacks you need to call, and then you call the 'finish'
callback to close out the request. We'd have to rev the master
function's API as we add new subcommands.
> > Is the question you're asking: "Why one hook, instead of a separate
> > hook for each feature?"
>
> That too. A hook script which simply acts as a dispatch layer for
> another set of hooks is needless indirection as well.
Actually, I think that's separable from the always-use-one-turnaround
part of the proposal, and we could indeed use N hook scripts.
I'm trying to think why it seemed to me so elegant to use just one,
but I'm unable to come up with a reason I can articulate, except that
it would be in some sense symmetrical with the RA interface. I'm not
sure that's a good enough reason to justify it as a user-visible
interface, though.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 18 07:15:22 2005