Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie

[Casey Marshall]

On Dec 6, 2005, at 11:57 PM, Raif S. Naffah wrote:

> On Wednesday 07 December 2005 04:49, Casey Marshall wrote:
> > On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote:
> > > On Tuesday 06 December 2005 18:42, Casey Marshall wrote:
> > > > A few of us have been throwing around the idea of merging GNU
> > > > Crypto and Jessie into GNU Classpath, so Classpath will have full
> > > > support for crypto and SSL "out of the box." We've proposed this
> > > > before, and I think this idea was mostly approved by the group,
> > > > but no-one ever got around to doing it.
> > > >
> > > > I'd like to propose again that we do this. I'll try to get to this
> > > > myself, but if I can't get this done, we'll at least have a plan
> > > > of action. I propose that we
> > > >
> > > >    - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in
> > > > GNU Crypto, and merge the current CVS sources into Classpath (not
> > > > under external/). We then put GNU Crypto into a kind of "stasis"
> > > > mode, and continue to develop these sources in Classpath.
> > > >    - Rename the root package 'org.metastatic.jessie' to
> > > > 'gnu.javax.net.ssl' in Jessie, and merge the current sources.
> > > > Then, I'll stop developing that branch on its own.
> > >
> > > does this mean that Classpath's crypto classes will be using the
> > > GNU Crypto "assembly, cipher, hash, key, mac, mode, pad, prng and
> > > "sig" sub-packages with the "jce" wrappers?
> >
> > Basically yes. The goal is to merge "everything with a JCE wrapper,"
> > because that will fill in many algorithms present in proprietary VMs,
> > but currently missing in Classpath.
>
> cool.  i can help with this task  --can spend ~2hrs/day on this until
> it's done.

Great! School's out for me right now, so I have my weekends back :-)

> > Things without JCE wrappers don't really make sense for Classpath,
> > because they aren't portably accessible.
>
> dont know exactly what you mean by this but i'll have a closer look at
> the Classpath classes; it may become evident then.

By this I mean that if something can't be used through J2SE classes,  
then it probably shouldn't be merged, because otherwise we'd be  
introducing private, non-portable APIs into Classpath. Exceptions are  
things we know we'll need to use privately (e.g., if Jessie needs it).

The assembly package is a good example: it's a neat, advanced API,  
but doesn't have any analogue in the J2SE spec.

Thanks.