"Simon Marlow"
Question 1: there's a comment next to 'FileFormat' which mentions that 'Codec' might be a more accurate name. It seems to me that 'Codec' would indeed be a better choice: many of the libraries under FileFormat are more like pure stream-transformers than file formats, and Codec encompasses both. What do people think about changing this? (there aren't any other implementations of libraries under FileFormat that I'm aware of).
I concur that Codec is a better name than FileFormat. It is more general, since the encodings may in fact never be stored in files - they could just be transmitted directly to a decoder over a network for instance.
If FileFormat became Codec, then the existing FileFormat.Encoding looks a bit odd. But moving FileFormat.Encoding.Base64 up to Codec.Base64 (similarly for FileFormat.Encoding.Yenc) would seem to make sense.
Since we already have a little hierarchy based on the codec's purpose: Codec.Image (e.g. Codec.Image.Jpeg) Codec.Video (e.g. Codec.Video.Mpeg2) then how about adding Codec.Text (e.g. Codec.Text.Base64) because its role, like uuencoding, is to convert binary streams to 7-bit ASCII text i.e. transmissible by email. A codec that is truly multi-purposed would sit directly under Codec, but I can't immediately think of an example that might fit.
Question 2: what should the insides of the FileFormat.Encryption (or Codec.Encryption) hierarchy look like?
I would have thought that its population would look something like: Codec.Encryption.DES Codec.Encryption.RSA Codec.Encryption.Blowfish etc. No need for any deeper structure. Any attempt to further classify crypto schemes by method or purpose would be confusing I think. Crypto is just crypto, i.e. binary to binary. Regards, Malcolm