Should tcl variables be able to hold binary data?

[Dr. Dieter Maurer]

I have thought to use tcl as a tool to access a multimedia database.
But, such a database may contain records with binary fields.
Of cause, it is not senseful, to load a complete image object into
a tcl variable, but loading the header and extracting useful information
could help a lot.
Unfortunately, the content of a tcl variable ends at the first binary 0.

Should tcl variables learn in the future to hold binary data?

Best regards
Dieter

[Kumar Srinivas]

We had similar need for it with database type BLOB -
Binary Large Object and TEXT in Informix.
We resolved it using hex characters for BLOB thus allowing
TCL to function as is.
It also makes it easier since the hex dump of the binary data is
displayable, printable to file, socket etc. and the input reader
converts the hex into binary before inserting into database.

We could also do some fancy things like
insert into <TEXT-type-object> select * from <BLOB-type-object>
allowing the data to be converted !

Thus you could do things like
set x "F7F7F7F7AA0133"
and interpret it.

--
Kumar Srinivas

[Ron Natalie]

Kumar Srinivas (ku...@tsi.gte.com) wrote:
: We had similar need for it with database type BLOB -

: Binary Large Object and TEXT in Informix.
: We resolved it using hex characters for BLOB thus allowing
: TCL to function as is.
: It also makes it easier since the hex dump of the binary data is
: displayable, printable to file, socket etc. and the input reader
: converts the hex into binary before inserting into database.

Another idea is the ASC85 encoding that is in the PixScript II
spec. This encapsulates 4 binary bytes in 5 printable bytes.
The code to map back and forth is pretty trivial.

-Ron

[Michael Schumacher]

Dr. Dieter Maurer (die...@hit.handshake.de) wrote:
: I have thought to use tcl as a tool to access a multimedia database.
: But, such a database may contain records with binary fields.
: Of cause, it is not senseful, to load a complete image object into
: a tcl variable, but loading the header and extracting useful information
: could help a lot.
: Unfortunately, the content of a tcl variable ends at the first binary 0.

: Should tcl variables learn in the future to hold binary data?

Yep, this is gonna happen RSN (John recently said that binary I/O would
be part of Tcl 7.6). In the meanwhile you have at least two options:

- write a minimal set of functions necessary to access the mmdb, and make
them available to Tclland

- use "read $stream 1" to read the input stream characterwise, then
compare each read character against the empty string (which will
return 1 in case of null bytes)

I'm also pretty sure that some Tcl extensions can handle binary I/O, so
snarfing through the Tcl archives and the FAQ might be helpful, too.

mike

[Klaus Ripke]

Dr. Dieter Maurer wrote:
>
> Should tcl variables learn in the future to hold binary data?
>

probably not in general, as this would introduce much incompatibility.
However, a do-it-yourself binary extension is pretty easily set up.

We employ some internal representation for binary records,
using a hash table per "record type" to map "field names" to offset and datatype.
Arrays and other structured fields are simply mapped to composed names like a.b and c,4 .
Such an internal description is built by a tcl command taking a list of name-type pairs.

The record may be realized either by tracing some tcl array,
which gives a very builtin look using set and $ substition and enables proc scope,
or as a command, which is more OO like and less "dirty trick".

Maybe we can make some source publicly available ...

--
Klaus Ripke fon: +49-30-467007 92
SOFTWERKer GmbH Berlin fax: +49-30-467007 93
Gustav Meyer Allee 25, 13355 mail: ri...@softwerker.de