(cvsclient.info.gz) Protocol Notes

 
 6 Notes on the Protocol
 ***********************
 
 A number of enhancements are possible.  Also see the file TODO in the
 CVS source distribution, which has further ideas concerning various
 aspects of CVS, some of which impact the protocol.  Similarly, the
 `http://www.cvshome.org' site, in particular the `Development' pages.
 
    * The `Modified' request could be speeded up by sending diffs rather
      than entire files.  The client would need some way to keep the
      version of the file which was originally checked out; probably
      requiring the use of "cvs edit" in this case is the most sensible
      course (the "cvs edit" could be handled by a package like VC for
      emacs).  This would also allow local operation of `cvs diff'
      without arguments.
 
    * The fact that `pserver' requires an extra network turnaround in
      order to perform authentication would be nice to avoid.  This
      relates to the issue of reporting errors; probably the clean
      solution is to defer the error until the client has issued a
      request which expects a response.  To some extent this might
      relate to the next item (in terms of how easy it is to skip a
      whole bunch of requests until we get to one that expects a
      response).  I know that the kerberos code doesn't wait in this
      fashion, but that probably can cause network deadlocks and perhaps
      future problems running over a transport which is more transaction
      oriented than TCP.  On the other hand I'm not sure it is wise to
      make the client conduct a lengthy upload only to find there is an
      authentication failure.
 
    * The protocol uses an extra network turnaround for protocol
      negotiation (`valid-requests').  It might be nice to avoid this by
      having the client be able to send requests and tell the server to
      ignore them if they are unrecognized (different requests could
      produce a fatal error if unrecognized).  To do this there should
      be a standard syntax for requests.  For example, perhaps all
      future requests should be a single line, with mechanisms analogous
      to `Argumentx', or several requests working together, to provide
      greater amounts of information.  Or there might be a standard
      mechanism for counted data (analogous to that used by `Modified')
      or continuation lines (like a generalized `Argumentx').  It would
      be useful to compare what HTTP is planning in this area; last I
      looked they were contemplating something called Protocol Extension
      Protocol but I haven't looked at the relevant IETF documents in
      any detail.  Obviously, we want something as simple as possible
      (but no simpler).
 
    * The scrambling algorithm in the CVS client and server actually
      support more characters than those documented in  Password
      scrambling.  Someday we are going to either have to document
      them all (but this is not as easy as it may look, see below), or
      (gradually and with adequate process) phase out the support for
      other characters in the CVS implementation.  This business of
      having the feature partly undocumented isn't a desirable state
      long-term.
 
      The problem with documenting other characters is that unless we
      know what character set is in use, there is no way to make a
      password portable from one system to another.  For example, a with
      a circle on top might have different encodings in different
      character sets.
 
      It _almost_ works to say that the client picks an arbitrary,
      unknown character set (indeed, having the CVS client know what
      character set the user has in mind is a hard problem otherwise),
      and scrambles according to a certain octet<->octet mapping.  There
      are two problems with this.  One is that the protocol has no way
      to transmit character 10 decimal (linefeed), and the current
      server and clients have no way to handle 0 decimal (NUL).  This
      may cause problems with certain multibyte character sets, in which
      octets 10 and 0 will appear in the middle of other characters.
      The other problem, which is more minor and possibly not worth
      worrying about, is that someone can type a password on one system
      and then go to another system which uses a different encoding for
      the same characters, and have their password not work.
 
      The restriction to the ISO646 invariant subset is the best
      approach for strings which are not particularly significant to
      users.  Passwords are visible enough that this is somewhat
      doubtful as applied here.  ISO646 does, however, have the virtue
      (!?) of offending everyone.  It is easy to say "But the $ is right
      on people's keyboards!  Surely we can't forbid that".  From a
      human factors point of view, that makes quite a bit of sense.  The
      contrary argument, of course, is that a with a circle on top, or
      some of the characters poorly handled by Unicode, are on
      _someone_'s keyboard.
Info Catalog
(cvsclient.info.gz) Protocol
(cvsclient.info.gz) Top
automatically generated byinfo2html