FW: First Attempt at Crypto Library

[Ketil Z. Malde]

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

>> Is a deep hierarchy really necessary?

> Well, it seems useful to group codecs by purpose: Audio, Video,
> Compression, etc. so I believe we're not into diminishing returns at
> this level.

Agreed, this is sensible.  But if you introduce orthogonal categories,
(e.g. Codec.Binary), you need to ask whether you should have

        Codec.Binary.Image.Jpeg
or      Codec.Image.Binary.Jpeg

and so on.  Slightly contrieved, perhaps, but diminishing returns is
just around the corner. 

> That's a good point.  Unless anyone objects, let's reserve Codec.Text
> for the text encodings (UTF-8 and so on).

Sounds reasonable, too.

> The options for Base64 and friends are therefore: 

> Codec.Binary.Base64,

I don't like it, since it's not obvious to me what property "Binary"
describes.  Most codecs work on binary data, don't they?

> Codec.General.Base64

The only reason for a "General" category would seem to me if we only
allow leaf modules.

> Or even Codec.BinaryToText.Base64?  

Very specific, but all right if we really need this level of
specificity. 

> Codec.Base64,

My choice, I think.

> but we could defer the decision until the library actually exists ;-)

Good point.  However, with third parties building libraries
(e.g. Shae et al.'s SourceForge suff), it would be nice to have a well
structured hierarchy in place, so that moving stuff back and forth
could be done with the least impact.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants