On Jan 6, 2006, at 12:41 AM, Raif S. Naffah wrote:
On Friday 06 January 2006 10:07, Casey Marshall wrote:
After thinking about exportability a little more, I think the best
option may be to not provide any `--disable-crypto' option at all,
and just structure the source code so that packagers can remove all
non-exportable crypto by just removing whole directories. The build
system doesn't care if you remove an entire package, anyway.
This is a little closer to what Raif suggested, but I'd suggest not
doing it by splitting the hierarchy up. That is, instead of making
the boundary:
<root>/gnu/javax/crypto/prng <-- weak algs
<root>/non-export/gnu/javax/crypto/prng <-- strong algs
We just shove exportable algorithms and providers under `gnu/java/
security,' and non-exportable algorithms and providers under `gnu/
javax/crypto.' Thus, if you need to make an exportable source/binary,
just `rm -rf {,gnu/}javax/crypto.' It's more of a manual process, but
very easy.
How does this sound?
how do you address the Factory classes? a Factory for a split
"service"
must see all its subordinates, which are different depending on
whether
the non-exportable stuff is in or out. yes?
Splitting into strong and weak factories might be the best bet.
Otherwise, I'd instead try using reflection for the strong
algorithms, which may not exist at runtime. There will be a split
between JCE providers on strong/weak boundaries anyway.
This seems kind of academic, though, because I don't think there are
many packages that need to be split in half based on strength (PRNG,
obviously. Anything else?). Also, we don't really need the Factory
classes in most places, like the JCE adapters, because we can just
replace calls to
FooFactory.getInstance ("Bar");
to
new Bar ();
As a stand-alone API, the factory classes should have used reflection
and had some amount of configurability, because as-is they aren't all
that flexible.
And, these classes are all internal, so it doesn't have to make any
sense beyond what we need to implement our security providers.
_______________________________________________
Classpath-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath-patches
