On Mon, 24 Jul 2000, Jon Miner wrote:
> Does anybody have any comments on this? I was guessing I'd get some
> comment, at least.
>
> jon
>
> > [...]
> > Instead of completely reinventing the wheel, I came to the realization
> > that what we really need is a CVS library that various programs (the
> > "cvs" executable, most notably) can access via a specified API. This
> > would allow for many different interfaces to CVS, especially the
> > graphical ones, as they could just link to the CVS library rather than
> > either shelling out to the executable or reimplementing anything.. It
> > could also be used to create a sort of PAM interface, allowing things
> > like cvsauth to be done in minimal code, without reimplementing
> > anything..
> > [...]
I also suggested this at least two time some month ago, but I also got
very little response. Maybe, now the time has come. In my oppinion it's
a great waste of time an resources to reinvent the wheel again and again.
I must admit that I do not know the CVS code very well and I currently
have no time, too. But here are some suggestions which parts of CVS
may be be handled by separate libraries
- A library to handle the repository stuff:
The repository stuff is not needed for graphical clients.
- A library to handle the working directory stuff:
Can be used by graphical clients and is not neccessary for pure
servers.
- A library to handle the access to the repository (e.g. local mode,
pserver, nserver etc.):
This would allow the possible use of different client / server
protocols, too.
- A library for parsing / accessing / modifying the logfile:
This would allow independent applications to access the logfiles in a
controlled and well defined way.
- Authetification and encryption.
Maybe this could be done in the way Tcl/Tk handles extension. The tclsh
main programm only consists of a few initialisations and then calls the
interpreter, which is part of the tcl library. Extensions are easy to
implement by simply defining some new commands, writing the C-code for
them and calling the interpreter.
Splitting the code into different libraries with clearly defined APIs
would also allow easier and better testing and enhances the stability,
since errors or changes in one library will not directly affect other
parts of the code.
Lars
-------------------------------------------------------------------
aerodata Flugmesstechnik GmbH Email [EMAIL PROTECTED]
Lars-Christian Schulze WWW www.aerodata.de
Hermann-Blenk-Str. 36 Voice +49 531 2359-188
D-38108 Braunschweig Fax +49 531 2359-158
