On Saturday 07 January 2006 12:58, Casey Marshall wrote: > On Jan 6, 2006, at 5:41 PM, Raif S. Naffah wrote: > > On Saturday 07 January 2006 11:32, Casey Marshall wrote: > >> You have to do that if you want to present a unified factory > >> interface to (e.g.) all PRNG implementations. But we don't have to > >> do that, here, because there already is a unified factory for > >> PRNGs: java.security.SecureRandom, and that's the one that makes > >> sense for Classpath. The weak provider queries the weak PRNG > >> factory, and the strong provider queries the strong factory. > > > > i was under the impression that it would be desirable to have that > > behind the JCE facade so that internally to Classpath, all > > crypto-related classes can get what they need without using the JCE > > mechanism. > > Yes, it would be nice to have Classpath's crypto internals (based on > GNU Crypto and Jessie) had a decent API for maintainers to use, but > it's something I'm willing to sacrifice to more cleanly split weak/ > strong crypto packages. I'm saying that since this API is internal, > it is OK if it's a little rough in places.
fair enough. > HOWEVER, if we write all Classpath-internal classes to use the JCE > whenever possible, the code is a lot more portable, and won't depend > on any specific crypto implementation. being internal to Classpath, i don't think portability is an issue. let's stick with what we have so far: (1) strong and weak hierarchies and their factories, and (2) use those internally to Classpath. cheers; rsn
pgp3BjbfrJauN.pgp
Description: PGP signature
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
