FW: First Attempt at Crypto Library

[Malcolm Wallace]

"Simon Marlow" <simonmar@microsoft.com> writes:

> 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