[RFC] Horde_Cipher -> Crypt_Cipher

Hey, Having had a look at Horde_Cipher, and knowing it would be useful in my XML_Encrypt package, I would like some thoughts on releasing the current version of Horde_Cipher as Crypt_Cipher in PEAR. AFAICT it has no Horde dependencies and follows PEAR CS et al; The main reason I want feedback is this: Horde_Cipher is just an API for multiple encryption algorithms (blowfish, des, cast128, rc2, rc4 and also in blockmode some others stuff). So we have two conflicts: Firstly (and foremost IMO) we have Crypt_RC4 already, what should we do about the redundancy? Secondly, the current Crypt_* cipher stuff (RC4, CBC, XTEA) are single stand-alone packages, I can see about modifying Horde_Crypt to a) use the current Crypt_RC4 instead of theirs and b) and also add the others to it? Whilst looking up the names of the various Crypt_* packages I have come across Crypt_Crypt this seems to be going no-where... (please correct me if it is, but from "I should have something for you guys to look at tonight" post on 15th February 2003 to pear-dev theres been no releases) . I would like to propose the following: Ditch Crypt_Crypt (the name is a bit ambiguous because of the fact Crypt_* contains encryption and hashing packages. And do this: Crypt_Cipher - Unified API for *ONLY* Encryption Methods Crypt_Hash - Unified API *ONLY* for Hashing Methods This seems much more... verbose IMO. Anyways, just an RFC, I don't mind porting Horde_Cipher over in the ways I've mentioned. One last thing, if this is done, should the various encryption drivers provided with Horde_Cipher also be released as standalone packages so that they can be used on their own like the current Crypt_* packages aswell as with the Crypt_Cipher package... If that happens, it would *probably* be easiest to actually just write my own abstraction class atop the single packages? - Davey