Peder> SNMP Engine IDs are, according to RFC 2271, octet strings that
Peder> are "binary" in nature, i.e., they are usually not printable.
Peder> Scotty 3.0.0 beta (I use the version from November 4th 1998)
Peder> seems to treat the "engineID" session option as a printable
Peder> text - and this does not work very well when scotty discovers
Peder> an engine when an unprintable id. Scotty discovers and uses
Peder> the the engine id correctly, but if you use the "<session>
Peder> configure" or "<session> cget engineID" you don't get what you
Peder> expect.
The engineID is stored in a Tcl_Obj. This means that there is no
problem with the "binary" in nature of an engineID since Tcl 8.0 and
above claim to handle binary data stored in Tcl_Obj's. Yes, the
printed value (e.g. puts [$s cget -engineID] looks ugly. You can
format it into something human readable using the Tcl binary command.
The big question is whether the approach of representing engineIDs in
binary within Tcl is a good or bad idea. There are still a number of
Tcl commands that will not deal correctly with binary data and using a
binary representation makes it harder to debug things. On the other
hand, using a native representations sometimes avoids conversions.
Comments on which path to go are welcome.
Juergen
-- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289)-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.