Re: Re: [RFC] Horde_Cipher -> Crypt_Cipher

On Sun, Jul 27, 2003 at 03:02:09PM +0100, Davey wrote: Hi Davey, Please don't take any of my comments too personally. I might have the wrong impression of what you're trying to accomplish here. > And to all maintainers, you know your code and presumably you know the > algorithms and stuff that lie beneath them whereas I do not, ... You admit that you don't understand the way this code works and yet you're trying to refactor its design and distribution. I appreciate the fact that you're trying to champion a generalized cryptographic interface for PEAR, but I'm not sure I care for your approach. > Personally, I'd like to see each of the Horde_Cipher 'drivers' become > standalone packages with a central blocking package, this means that > when you only *need* DES, or blowfish, thats all you need to have. I > don't want to use an entire abstraction class with Auth_HMAC for > example, I *know* I'm only going to be using HMAC and nothing else. I don't see the value in splitting up the Horde_Cipher package into "drivers". It will just increase the management overhead, and it will require the "base" interface and package consumers to do too many things conditionally. Imagine that I write some code that uses your new PEAR cryptographic interface. I wouldn't be able to rely on a specific cipher being always available because I couldn't guarantee (without runtime testing) that the site has that "driver" installed. Your argument about not *need*'ed certain drivers doesn't really hold water. The classes aren't that big nor do they pollute the PEAR namespace. _Not_ having them installed with the rest of the crypto infrastructure doesn't buy you anything. As someone pointed out earlier, we don't distribute PEAR::(DB|MDB) drivers separately; that degree of granularity is excessive. I only see disadvantages to this driver model. > I think once the current package owners have answered the questions > above, we'll have a clearer idea of what wants doing, and then I'll just > get on and do it. I don't much care for your attitude toward the existing package authors. It feels like your trying to hold them responsible for explaining the details and implementation of their packages to you. While that's not unreasonable, I think there's a certain expectation for you to do this work yourself. You've admitted twice on the Horde mailing list that you a) don't understand the way crypto code works, and b) you haven't actually looked at the Horde_Cipher code. I don't understand how you can be proposing reorganizations to code that you haven't seen. So, in summary, (and I'm biased here), I think the Horde_Cipher package is the most complete crypto implementation we have available right now. The code is living happily in Horde CVS, and Mike (Cochrane) has stated that he won't support a "driver" model. The Horde_Cipher code has also been "PEAR-ized" in that it conforms to the coding standards and is package-able. If the only problem here is distribution, we can make the package available via pear.horde.org. I see no reason to morph the code into something else or to even import the code into PEAR CVS. -- Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)