Well, I'm not a CVS developer, but here's my $.02 anyway.
On Tue, Aug 22, 2000 at 11:12:34AM -0600, Derek R. Price wrote:
> "KOIE Hidetaka ($B8q9>1QN4(B)" wrote:
> > From: "Derek R. Price" <[EMAIL PROTECTED]>
> > Subject: Minor client/server bug
> > Date: Wed, 9 Aug 2000 14:29:34 +0900 (JST)
> >
> > | When commands are run that instruct you to rerun cvs, the name of the
> > | executable on the server side is printed rather than the name on the
> > | client side
> >
> > I have made a patch.
> > Summary:
> > [the client sends its name to the server, for inclusion in
> > error messages]
>
> I was looking at this and it doesn't look like the right fix - there's really no
>reason for the
> server to know the name of the client executable.
As an aside, I don't actually see what's so bad about the server
knowing the client's name for display purposes, as long as it
never actually tries to *run* the client. (Note, it doesn't have
to know the path to the executable; in one common case, it would
make sense for the client to report its name as "WinCVS", not as
"C:\progra~1\whatev~1\wincvs.exe".)
> I researched it a little and I see two
> possibilities which leave the error message intact:
>
> 1) Have the client assume from the "Checked-in" server response on added files and
>the
> "Remove-entry" server response on removed files that this message needs to be
>printed.
> 2) Expand the 'MT' piece of the client/server protocol [...] so that
> the client knows the message type and which variables to parse for then constructs a
>message on
> its end (including the local executable name, of course).
> The reason I ask is that it seems to me that the precedent is to go with #2,
Given that the MT mechanism exists, however, it seems to me the
best approach. This is exactly what it's for, after all.
I disagree about sending only the variables and letting the
client construct the message, though. Judging (only) by
cvsclient.texi, the precedent is to construct the entire message
on the server, out of a combination of variables and "MT text"
constant strings. More important than being the precedent, this
approach means that the user will get a somewhat-useful message
even if the client is too old to recognize those particular MT
tags.
On the other hand, of course, is that your approach works better
for windowing clients. The client can assemble the variables
with its own text into a message that makes more sense in
context: instead of "type `cvs update -j...'", it can say "choose
`update' from the XYZ menu, then...".
But the two aren't necessarily incompatible. With the existing
scheme of "MT text"s interspersed with variables, the client
could always ignore the former and supply its own.
One simple protocol extension would cover all the possibilities,
it seems to me. Add this MT tag, valid in any context:
MT cvsprogram cvs
The server always sets the DATA to the string "cvs". If the
client recognizes the "cvsprogram" tag, it ignores the DATA and
prints whatever user-friendly name it wants to call itself.
Otherwise, of course, it just spits out the DATA as raw text, but
the server's choice of data makes the resulting message still
somewhat sensible.
> [...] letting the server
> be the source of all error messages which aren't due to a client problem (e.g. local
>file
> permissions, unavailable network, etc.). This makes sense to me, from the
>perspective that a
> "stupid client" means that much server operation is invisible to the client, a
>client only
> needs to know things it can be commanded to do directly, e.g. merge files, set
>sticky tags, or
> remove an entry, leading to clients which require upgrades less frequently despite
>possibly
> frequent server upgrades.
Agreed. Having the client intuit when a message is necessary, or
what its contents should be, is ugly, fragile, and hard to
extend.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
Nobody ever got fired for buying Microsoft -- but they could get
fired for relying on Microsoft.
- Chris Garrigues
