Re: Discussion of SCM_SVN Proposal

Hi, all,

Chora is under no obligation to use my package, whether or not it lives in PEAR or doesn't. The Horde guys will have to make that decision on their own, just like any developer of a database-driven application decides among using native PHP extensions, a third-party package like ADOdb, PEAR DB or PEAR MDB, or the third option that some people choose of rolling their own mini-abstraction layer. To each his own -- what Horde does or does not adopt for the Chora application is up to them.

While a HORDE alliance may be good in general, HORDE compliance is not a stated barrier to PEAR entry. Personally, I'd like to see more cooperation between the two (c.f. the proxy proposal of Text_Diff, which has more votes for it than any other proposal in the system ;-) ... but I have zero problem with a PEAR-specific SCM package if an extant HORDE implementation does not fit the proposer's vision. Clay, how hard do you think it would be to extend or reuse the SCM_SVN model to work with CVS or RCS? I ask only for the future of the category and/or tools like SCM_SVN in PEAR.

It was not my intention to stir up some hornet's nest, or to propose something that would be perceived by anyone as a competitor to Horde.

Myself, I don't see PEAR as a competitor to HORDE. I think the two can achieve a good and fruitful symbiosis, if enough members on each side can find common ground.

I've proposed a low level API for the PEAR project -- I'm just trying to fill a small hole that I saw (and still see) in PEAR's otherwise robust offerings.

And a good fill it looks to be. As you say, nobody in PEAR has scratched that itch. -- Paul M. Jones pmjones@ciaweb.net Savant: the simple alternative to Smarty. http://phpsavant.com/