(devel-cvs seems to be a bit broken, so I guess it'll just be
info-cvs..)
I know this has been brought up before, and I didn't really think that
there was much use for it at that point, but....
I've been working on Apache mod_cvs ( http://www.sub.nu/mod_cvs/ ) and I
was thinking about trying to make it more efficient, and able to
communicate with CVS servers across the network..
This, of course, is a complete change to the current functionality of
mod_cvs (which does work quite well, it seems) and has the posibility of
slowing down the web access VERY MUCH.. But, I figured I'd try anyway.
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..
Has anybody looked in to this already? It would certainly be a major
architectural change, probably necessitating a 2.x.x release..
just some thoughts..
jon
--
.Jonathan J. Miner------------------Division of Information Technology.
|[EMAIL PROTECTED] University Of Wisconsin - Madison|
|608/262.9655 Room 3149 Computer Science|
`---------------------------------------------------------------------'
That means I'll have to use $ans to suppress newlines now.
Life is ridiculous.
-- Larry Wall in Configure from the perl distribution
