On 17 May 2005 17:32:51 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > But log templates require a specific kind of input (the directories to
> > be committed) which makes no sense for other kinds of server-to-client
> > configuration under discussion.
>
> Wait, though. I think we may be on to something:
>
> If a path list doesn't make sense for other kinds of server-to-client
> configurations, then the client need not send it. As long as the
> client knows not to send it, and the server knows not to expect it,
> everything's fine.
>
> In other words -- trying to think big here -- generalize the proposal:
>
> Have a generic repos hook called 'inquiry'. It can read its
> parameters (the first parameter is always a subcommand) and read
> stdin, and depending on the subcommand it may or may not write to
> stdout. We define calling disciplines for various subcommands: what
> further parameters they take, what if anything to expect on stdin, and
> what if anything they can write to stdout.
Sounds like a reasonable plan.
> The first subcommand we define is 'log-message-template'. It
> (perhaps) takes one optional additional parameter, the author, and it
> expects a newline-separated list of paths on stdin. Anything it
For generality, it might be useful to pass everything but the
subcommand on stdin (perhaps as key-value pairs?), so the hook script
could parse its args and dispatch easily.
> writes to stdout gets sent back to the client as the log message
> template. If it writes nothing, the client gets no template and
> behaves as it does today. We ship with a default ("suggested serving
> size") implementation of this subcommand, but anyone is free to
> implement their own inquiry hook of course.
Perhaps the "default" log message template would produce what's used
now, so a repository admin could change that.
> And, the best part:
>
> We make sure that from the first release of this feature, all RA
> layers have a way for the client to send multiple inquiries & their
> parameters in one request, and a way for the server to reply with all
> the answers in one response. That way we can add new features later
> without adding more network turnarounds.
I don't know how deeply subversion/libs understand MIME, but a MIME
digest might work nicely here.
For best flexibility, I'd guess that the server should just return an
"unimplemented" reply to an unknown message, and the client should
have sensible default behavior for a missing/"unimplemented" reply.
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 18 01:27:23 2005