On Tue, 14 Oct 2003 01:17:12 +0100, "Julian Foad"
<julianfoad@btopenworld.com> said:
> C. Michael Pilato wrote:
> > Julian Foad <julianfoad@btopenworld.com> writes:
> >
> >>kfogel@collab.net writes:
> >>
> >>>To have both streaminess and sortedness is hard. Just ask CMike :-).
[snip]
>
> The server making the same 'sort' promises is the bit that I hadn't
> thought of as a problem, but I see now that it has to be dealt with
> carefully. Since my primary goal is to make the output non-arbitrary,
> any simple fixed sort order would suffice.[2] Such an order could be
> introduced at the server, and then later promised by the protocol, and
> then perhaps at some later date relied upon by the client. Only the last
> stage, the client relying on it, has backwards compatibility
> implications, and those could be satisfied by a gap of two releases[3]
> and/or by an implementation which takes care to fall back gracefully to
> unsorted output (rather than breaking) when run against a non-sorted
> server.
>
> Note also that even without the client relying on such a promise, it can
> still get the benefit of a sorted order in all client-only and all
> server-only operations, i.e. most operations other than "status -u" and
> "update".
[snip]
If the user specifically *requests* sortedness, couldn't the client just
buffer output, sort it, and then stream it to the UI layer ? I would
believe that this way, most of the code stays untouched... Of course, I
do not have the expertise at the moment to check or implement this, but
that is how I would implement it, given another language.
On the other hand, pipe the command's output through sort and be done
with it ?
Thanks,
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 14 02:34:09 2003