RE: FW: First Attempt at Crypto Library
I initially thought along these lines, but then concluded that it's not that simple (or at least, that's not the only interpretation of the classification).
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. Matt Harden said:
I would agree with Codec.Binary.Base64. Codec.Text should be reserved for codecs that deal with text data; i.e. translating text between various encodings like unicode, ISO 8859-1, ascii, ebcdic, etc.
That's a good point. Unless anyone objects, let's reserve Codec.Text for the text encodings (UTF-8 and so on). The options for Base64 and friends are therefore: Codec.Binary.Base64, Codec.Base64, or Codec.General.Base64. Or even Codec.BinaryToText.Base64? None stands out as the obvious choice to me, but we could defer the decision until the library actually exists ;-) Cheers, Simon
"Simon Marlow"
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
G'day all. On Wed, Apr 23, 2003 at 11:12:44AM +0200, Ketil Z. Malde wrote:
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
This case is fairly simple. The Jpeg codec does not encode/decode "binaries", it handles abstract "images". (In fact, it's a strict subset of "images", namely, images with three 8-bit channels, where the channels represent RGB space or something else easily converted to RGB.) I'm still not convinced that Codec.Image makes sense in isolation from a representation of "images". It's hard to see what you'd do with such a library without some other image handling stuff. Cheers, Andrew Bromage
Andrew J Bromage
This case is fairly simple. The Jpeg codec does not encode/decode "binaries", it handles abstract "images".
It handles binary data, surely? But I'm quite convinced that the word "binary" has way too many interpretations, and applies in way too many cases, to be a good name for a level in a library hierarchy.
I'm still not convinced that Codec.Image makes sense in isolation from a representation of "images". It's hard to see what you'd do with such a library without some other image handling stuff.
What do you mean - are you talking about a *module* Codec.Image as opposed to a directory (which is, AFAIK, the only suggestion previously on the table)? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
ketil@ii.uib.no (Ketil Z. Malde) writes:
I'm still not convinced that Codec.Image makes sense in isolation from a representation of "images". It's hard to see what you'd do with such a library without some other image handling stuff.
What do you mean - are you talking about a *module* Codec.Image as opposed to a directory (which is, AFAIK, the only suggestion previously on the table)?
Oh, never mind. I see now, it's the "Codec" prefix that's ailing you. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
G'day all. On Thu, Apr 24, 2003 at 08:21:59AM +0200, Ketil Z. Malde wrote:
It handles binary data, surely?
Not in the same sense that Deflate does. An arbitrary binary stream is not, in general, JPEG-compressible. You at least need a width & height as metadata, plus a number of 3-byte triples equal to width*height.
I'm still not convinced that Codec.Image makes sense in isolation from a representation of "images". It's hard to see what you'd do with such a library without some other image handling stuff.
What do you mean - are you talking about a *module* Codec.Image as opposed to a directory (which is, AFAIK, the only suggestion previously on the table)?
No, I'm talking about a Codec.Image directory (as opposed to something more like Image.Codec, which IMO makes far more sense). Cheers, Andrew Bromage
Andrew J Bromage wrote:
On Thu, Apr 24, 2003 at 08:21:59AM +0200, Ketil Z. Malde wrote:
It handles binary data, surely?
Not in the same sense that Deflate does. An arbitrary binary stream is not, in general, JPEG-compressible. You at least need a width & height as metadata, plus a number of 3-byte triples equal to width*height.
Not to mention that it assumes those triples represent a two-dimensional field of RGB colour values - the algorithm performs a colour transformation first (into YUV), then a 2D spatial transform. Arbitrary binary data will cause the algorithm to behave arbitrarily badly when it tries this! You'll just get noise out the other end. --KW 8-)
ons 2003-04-23 klockan 10.52 skrev Simon Marlow:
That's a good point. Unless anyone objects, let's reserve Codec.Text for the text encodings (UTF-8 and so on).
Definitely.
The options for Base64 and friends are therefore: Codec.Binary.Base64, Codec.Base64, or Codec.General.Base64. Or even Codec.BinaryToText.Base64? None stands out as the obvious choice to me, but we could defer the decision until the library actually exists ;-)
Never do today, what you can put off until tomorrow, eh? :) I think "Binary" is a bad name. What does it mean anyway? I don't think it adds any information to have Codec.Binary.Base64 rather than Codec.Base64. What other interesting encodings would you put in Codec.Binary? /Martin -- Martin Sjögren sjogren@debian.org -- marvin@dum.chalmers.se GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html let hello = "hello" : hello in putStr (unlines hello)
On Wed, Apr 23, 2003 at 11:17:04AM +0200, Martin Sjgren wrote:
Never do today, what you can put off until tomorrow, eh? :) I think "Binary" is a bad name. What does it mean anyway? I don't think it adds any information to have Codec.Binary.Base64 rather than Codec.Base64. What other interesting encodings would you put in Codec.Binary?
The obvious answer is Codec.Binary.Uuencode! :) But I agree, Codec.Base64 sounds simpler and better. -- David Roundy http://www.abridgegame.org
David Roundy
The obvious answer is Codec.Binary.Uuencode! :) But I agree, Codec.Base64 sounds simpler and better.
I also vote for this option. The Haskell community is small enough that we can just change it later if a flaw is found. -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion 10 PRINT "HELLO" 20 GOTO 10 ; putStr $ fix ("HELLO\n"++)
Martin Sjögren wrote:
ons 2003-04-23 klockan 10.52 skrev Simon Marlow:
The options for Base64 and friends are therefore: Codec.Binary.Base64, Codec.Base64, or Codec.General.Base64. Or even Codec.BinaryToText.Base64? None stands out as the obvious choice to me, but we could defer the decision until the library actually exists ;-)
Never do today, what you can put off until tomorrow, eh? :) I think "Binary" is a bad name. What does it mean anyway?
It's obvious to me. Binary means that the codec in question is designed to cope with arbitrary binary data. The codecs in the other categories *cannot* do that. If binary is a bad name, one could use OctetStream, which is more descriptive, but much less commonly used. I actually don't mind BinaryToText; it certainly says what it does.
... I don't think it adds any information to have Codec.Binary.Base64 rather than Codec.Base64. What other interesting encodings would you put in Codec.Binary?
QuotedPrintable UUencode {X,Y,Z}modem (protocols, not codecs? but I'm sure there's a codec or 2 in there somewhere) Yenc Base32 Motorola S-record format (OK, not so interesting) I seem to be in the minority (a minority of one?), but I don't want to have both modules and directories in the main Codec directory. It makes more sense to me if each codec module name had the consistent form: Codec.<Classification>.<Name> Thanks, Matt
participants (8)
-
Andrew J Bromage -
David Roundy -
Keith Wansbrough -
ketil＠ii.uib.no -
Martin Sjögren -
Matt Harden -
Shae Matijs Erisson -
Simon Marlow