On 8/20/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 15.08.2006, at 21:09, Stephen Deasey wrote:
> * is checking for bytearray type a good way to handle binary Tcl
> objects?
Hm... how would you (generally) check for a byte-array?
You can get a byte-array from object but you can't
(without looking into the object type which is really not
something that is portable) say which type of object you
are dealing with.
Sure you can:
byteArrayTypePtr = Tcl_GetObjType("bytearray");
if (objPtr->typePtr == byteArrayTypePtr) {
/* It's a bute array... */
}
I believe the main source of problem here is somebody
slurping the whole file and wanting to return that file
as-is i.e. w/o any translations. In that case, he/she
cound use [ns_conn encoding] to set the encoding of the
connection before calling ns_return. This way we can
strip away all the extra options from the content-returning
commands and request the writer to use ns_conn to set
the correct encoding OR to skip encoding altogether
(for example: ns_conn encoding binary).
Wouldn't that make sense?
I was thinking more of the case where you dynamically create a binary
object, like a 'captcha' image. You want to ns_return it and have the
server do the right thing without having to fiddle with a -binary
switch.
Another place where checking for a byte array might be good is the
caching code. when you cache an object, it first gets converted to a
valid utf-8 rep. When you get the object out of the cache, if you
treat it as a byte array, evrything still works -- the conversion from
byte array to utf-8 string and back again is non lossy. It's just non
optimal.
As we're starting to see things like the -binary switch spread, I was
wondering if it was, in general, a good idea to check for byte arrays
and have things work transparently. Are there any gotchas?
