[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcvs-spec-dev] CVSConnnectionPserver
From: |
Alexander Taler |
Subject: |
Re: [Libcvs-spec-dev] CVSConnnectionPserver |
Date: |
Wed, 08 Dec 2004 20:20:14 -0500 |
You appear to be referring to the recommended cvsclient
architecture:
http://www.gnu.org/software/libcvs-spec/guide/internals/CVSClient/generic.html
>>>>> "Alastair" == Alastair Growcott <address@hidden> writes:
Alastair> Since the password scrambling is particular to the pserver
Alastair> connection method, shouldn't the constructor for that class take an
Alastair> unscrambled password and manage the scrambling of it itself. It
Alastair> seems odd to put the scrambling code in any other class, frankly.
In the latest Perl code it takes a non-scrambled password. I
haven't updated that document in a while, I just moved over the
old version. The thing to think about however, is that the
.cvspass file contains scrambled password, so handing the
plaintext password to that class means that it has to deal with
the .cvspass internally. I took the internal course for the Perl
library.
Alastair> What is the intention of the CVSConnection classes? It seems a
Alastair> little unclear in many ways. What does the function
Alastair> getStreamToServer() do? How about getStreamFromServer()? I expected
Alastair> to see something like recv() and send() type functions.
In Perl (and Java) you generally keep streams as objects, since a
lot of the reading and writing functions are already done for you
that way. Those functions return regular classes, independent of
connection type, which you can read from or write to. Perhaps in
C recv() and send() would be better.
Alex
--
https://savannah.gnu.org/projects/libcvs-spec Access CVS through a library.
PGP: ID: 0x23DC453B FPR: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B
According to you, why to people pre-plan their funeral?
-- Question on an unsolicited survey from a local funeral home.