>And,
>please, avoid the pitfall, common in Java APIs, of obscuring the starting 
>point to support the plug-in model.  One thing I hate about Java APIs is 
>having to get a base class of something through some obtuse factory.  I 
>want to be able to say:
>
>   crypt = Blowfish.new
>
>not
>
>   crypt = Crypto.lookup( "Blowfish" ).new_instance
>
>Some libraries for Java are even worse than this.

I agree, it is horrible, but in all fairness you probably end up with
something like this if you try to define a completely general crypto
interface that:

	- allows you to plugin any backend (provider)
	- supports all existing and future cryptographic
		+ algorithms
            + modes of operation (ECB, OCB, CTR...)
		+ encodings
      - works with streaming data
	... etc

Java is enterprise-level "programming in the large" taken to its extreme.
All cases are covered: "OK, so you want a checkbox label which mixes
cyrillic, arabic (running in the opposite direction), kanji and braille with
a different font for each character --- we can do that." This
over-generality makes it awkward for simpler projects (and 98 % of the
projects are simpler). And since everything is provided in one big honking
runtime environment instead of in small loadable modules, it is impossible
to escape it.

In Ruby we can provide both a simple Blowfish.(rb|so) which is as simple as

	cipher_text = Blowfish.encrypt(plain_text, key)

for those who want that and a huge over-generalized CSP, if there ever is a
need for that. The only thing we need to fear are namespace collisions.

-- Niklas