-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
>> but I am sure that it can
>> read from cvs' stdout instead of stderr, too.
>
>
> Yes, it *could*. But at the moment it expects this particular input
from stderr and all (?) other versions of CVS servers send it at stderr.
There are already too much differences between GNU CVS and CVSNT...
>
>> Wouldn't it be more consistent to reserve stderr for
>> error messages, and to write log messages to stdout,
>> as usual?
>
>
> It would be more consistent, if the client-server protocol (and this is
what we are talking about) would send the information in a unambiguous
format and translate it *at client side* in human readable text.
Unfortunately, the CVS server already converts it to human readable
format and the more advanced clients need to parse it, which is not
possible correctly in all cases (e.g. imagine file names with spaces and
the output of the 'cvs history' command).
Hrm. What about using GNU gettext and tweaking the MT responses to
transmit messages as GNU gettext message keys and values to sub? The
gettext hooks are already in the feature release of CVS but it would be
a lot of work. MT should adapt pretty well since the client/server
protocol contract already states that MT stuff can be printed as is if
the client doesn't understand, though temporarily it might shuffle some
output away from stderr. For example:
MT +error
MT gettext This is an error message about a problem with
MT filename path/to/file.c
MT gettext on
MT datetime 2005-04-29 17:18 -
MT gettext . Do something about it.
MT newline
MT -error
Could be either printed verbatim, in legible english, by a client, or
converted to a call to gettext like:
gettext ("This is an error message about a problem with %1 on %2.
Do something about it.", var1, var2);
Or, at least I think so. I'm not sure how easy it is to dynamically
construct the gettext key, but I imagine someone must have run up
against a problem like this already.
A gettext conversion has been on my "nice to see" list for awhile now
anyhow. It would be nice to see a complete patch.
This all reminds me, I've been idly considering the advantages of
importing either the lightweight Expat XML parsing library or Gnome's
lightweight libxml and moving, eventually, to an XML format for
configuration files, trigger script input (since under the current
scheme, info passed to the trigger scripts are limited to whatever
environment limits are inherited from the shell, often 4096 bytes, I
think...).
XML would be simpler, more consistent, more extensible, and would solve
a lot of existing problems involving spaces in file names and whatnot,
possibly even unicode characters in paths.
I was also idly wondering about converting the client/server protocol as
well, though I don't know much about what it means to have a two-way
protocol using XML. Perhaps XMLRPC or the like would provide a clue?
Anyhow, I wasn't planning on doing any of this anytime soon, I just
thought it might be useful to see what sort of early discussions I could
start on the subjects.
Regards,
Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCcm5vLD1OTBfyMaQRAsmbAJ9/LQzfMX8cIG3gUFWL+x6kRI7NzQCgtRi4
Ndx5o1q+X+O/8ORWdjKCm/w=
=TPqr
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
