On Tue, Apr 22, 2003 at 12:15:41PM +0100, Malcolm Wallace wrote:
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.
Me too.
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.
I would have thought Codec.Binary.Base64, since in the other cases (Image and Video), the name is for the content you wish to code, not the format in which it is encoded. e.g. Jpeg is a format for encoding an image in binary, while xpm is a format for encoding an image as text, but both would go under Codec.Image.
A codec that is truly multi-purposed would sit directly under Codec, but I can't immediately think of an example that might fit.
gzip? Although that would probably go under Compression or something.
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.
I would imagine you'd want a Codec.Encryption.PublicKey and Codec.Encryption.Symmetric, since public key encryption supports a different set of operations from simple symmetric ciphers. I'd think that all symmetric encryption could use a common interface of some sort, but and perhaps all PK encryption could do the same, and it would be nice to reflect this in the hierarchy. Then you'd probably also want a Codec.Encryption.Hash for cryptographic hashes. I'd think you'd also want to create somewhere a module for converting a passphrase into a key of an arbitrary number of characters (which would probably be used by all the symmetric ciphers if they want to use a common interface), but here I'm revealing my ignorance of cryptography, since I don't know what such a thing is called. Some sort of variable-sized hash I guess... -- David Roundy http://www.abridgegame.org