Donal K. Fellows skrev:
>    TIP #317: EXTEND BINARY ENSEMBLE WITH BINARY ENCODINGS
[snip]
>    This TIP extends the *binary* command with implementations in C of
>    commonly used binary encodings. In particular the /base64/ encoding is
>    implemented 

The application domain for this feature is quite similar to that of 
"filters" in PDF [1, Sec. 3.3], so it might be interesting to compare 
the two.

PDF has two filters ASCIIHexDecode and ASCII85Decode similar to those 
of this TIP; the first presumably is the same as the suggested hex 
encoding, whereas the second is more comparable to base64/uuencode 
(though using a set of 85 characters to encode 4 bytes using 5 
character, rather than 3 bytes using 4 characters, so completely 
incompatible).

PDF also has a large number of filters related to compression: 
LZWDecode, FlateDecode, RunLengthDecode, CCITTFaxDecode, ...
Finally, there is a Crypt filter (which could just as well have been a 
family of filters) which does decryption of data.

One point is thus that there are other uses for [binary encode] than 
just ASCIIfying binary data, but that's fine, since

>    the Tcl ensemble scheme [TIP #112] can be used to
>    provide simple extension of the implemented formats.

A second point is however that the dictated syntax:

>    SPECIFICATION
>  ===============
>  
>    The *binary* command ensemble will be extended to include two new
>    subcommands, *encode* and *decode*. Each subcommand will accept two
>    arguments. The first is the name of an encoding format and the second
>    is the data to be operated upon.
>  
>          *binary encode* /format data/
>  
>          *binary decode* /format data/

may be too simplistic. Many of the compression decoders have additional 
parameters for the process (although these mainly concern the use of 
predictors to improve compression of sampled image data). An encryption 
decoder most definitely would need a parameter for the key. In general, 
I think explicitly allowing

   binary encode $format {*}$extraParameters $data

would be better (parameters before data simplifies creating aliases for 
conversions with certain parameter values). All block compression 
commands of TIP #234 (zlib compression) take an optional parameter.

A third point is that PDF filters can be composed; they can be 
specified as a list (or in PDF terminology, an array) which will be 
applied in sequence. The equivalent for [binary encode] would be that 
instead of

   binary encode $format $data

one would have the syntax

   binary encode $formatList $data

However, I think this would be an unnecessary complication. We have 
other means of composing operations. ;-)

Finally, there is of course the matter of whether these features like 
base64 encoding really need to be in the core, but I abstain from 
taking an opinion on that.

Lars Hellström


[1] PDF Reference, Fourth Edition, version 1.5;
see http://www.adobe.com/devnet/pdf/pdf_reference.html.
(This is not the newest version, but it's fairly nice,
and it's the last version available that doesn't require
an object stream capable reader.)


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core