-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Lars Hellström wrote:
[snip]
|>    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.

I agree. I've just modified the tcllib base64 code to make use of this
and in order to support the -maxlen and -wrapchar parameters I have to
post-process the base64 encoded data using [string range] and [append]
and it increases the time by an order of magnitude

% source b64.tcl
% set s [binary format @102400]; string length $s
102400
% time {base64::encode -maxlen 0 $s} 10
1265.9 microseconds per iteration
% time {base64::encode -maxlen 60 $s} 10
7546.0 microseconds per iteration

And as pointed out, some possible applications may require additional
options.

| 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. ;-)

This would be better handled using channels I think. The plan here is to
provide a fast encoding primitive that can be used with [chan create] to
create an encoding channel layer. Just providing a channel would be
limiting, providing a command for use in script-based channels seems
more general. I think this requires TIP 230 but I don't think thats
likely to be rejected.

Pat Thoyts

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)

iQCVAwUBSB7Yq2B90JXwhOSJAQiw7QP7Bc1iCqDTF+gwYTGnRir+Wtn6iRfvPEJ3
YEzEZdkOE0l7yxkzAibBCIWbLOW99QQV6UhOHNL/lotaS5m/JTqgGqNPGdKCGoWu
DYbvsHu/5+LaHEOJQnO0gSjgdjfWXgJaoktBfGgvPRPs4NIfETnrsldfwlLjrBoZ
gNjg8H3vdO0=
=Tqif
-----END PGP SIGNATURE-----


-------------------------------------------------------------------------
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