-----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 -0000 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