Greg Stein <gstein@lyra.org> writes:
> Woah, woah, woah...
>
> "send bytes" ... this design is predicated on sending an arbitrary set of
> human-readable bytes, and expecting the stream to get them to the
> person.
Perhaps you missed that next paragraph that translates to: "I know
this method ain't the greatest. There's a better one to be found in
v-tables." ??
Regardless, that's not to say there's no value in having a library
feedback stream. Consider CVS in "trace mode" (or whatever that
ultra-verbose mode is). Sure, we could get the same effect by using
printf's *on a command-line client*, but that type of high-noise
feedback a) should be easily separable from the "important stuff"
(like what the trace editors are printing to stdout), and b) should be
easily consumed and displayed by a GUI client (I'm picturing the
"Output" window of MSVC, the bottom-most status window in WS_FTP, and
a host of other programs that want to tell the user things so rapidly
that simply replacing the status-bar text doesn't give anyone a chance
to read what the hell is going on. And I simply can't see the
advantage in having a callback *function* for each and every type of
thing such a trace mode would like to tell someone. So you end up
settling on a single call-back function that just provides
human-readable text meant to be dumped to someplace useful. And
that's what this is -- that single callback function is called
stream->write().
Whatever. The part of that commit related to a feedback stream is
easily revertable. The breakout of pool stuff into their own header
file is something that should have been done a long time ago anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:31 2006