Re: TCL (was Re: [tkined] Monitoring a 3Com SuperStack II 3300 switch)

From: Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Date: Wed Feb 02 2000 - 12:53:50 MET


>>>>> Eddie Corns writes:

Eddie> Much as I dislike TCL, I like the way Scotty itself works.

[...]

I can't resist to tell you my current thinking about this topic (and I
hope that this does not kick off yet another language war).

When I started looking into SNMP, there was simply no good way to do
even little things without either writing ugly C code or using slow
and ugly shell scripts. Marshall Rose came up with a version of gawk
which could talk SNMP. But awk is a bad scripting language for
networking application - awk is cool for processing structured data
records but that's it.

So I looked around for something which allows me to experiment with
SNMP and other protocols in a very efficient way (means the time to
code an idea should be minimized). Remember, this was back in 1991.
So I stumbled across Tcl and it was great. The interpreter was small
and easy to extend and fast enough for my purposes. And the Tcl C
source code was a great thing - I learned a lot by reading it. And
even better, Tcl had Tk which was at that time an outstanding free GUI
toolkit for Unix boxes.

Poul-Henning Kamp then wrote in 1992 a Tcl wrapper around the CMU SNMP
API. I played with it but I did not really like the API. In fact, I
think that defining APIs that fit well into the host language is very
important. APIs that are only "stupid" wrappers around C APIs are
seldom good APIs in a scripting language. In 1993, Glenn Trewitt and
Poul-Henning Kamp wrote a paper on a new API (which was supposed to
support SNMPv2p as we call it now) and I still did not like the
API. Nor did I like Poul-Henning's the implementation very much - it
was not written in the same excellent style which was used for Tcl
itself and it was easy to trigger core dumps if your arguments looked
a bit strange.

In 1994, we did our own SNMP engine and we started out own API. And
this turned out to be really useful for us (and others). I have been
really surprised when Marshall Rose came up with his Tcl interface for
SNMP in the same year. Sure, I looked at Marshall's API. But again, I
did not like it and I again disliked the stability of his
implementation. (It was not uncommon to get a core dump if you entered
an invalid command).

Sure, our API has problems as well and we are going to fix some of
them. In fact, I learned a lot about the whole subject during the past
few years and I would not do everything the same today. And even the
SNMP folks have made progress - the architecture defined in RFC 2571
is a big step forward to actually define better APIs.

Back to Tcl itself. Tcl has grown quite a bit since I first had
contact with it. And I can't say that I like all the things that have
happened. The port to various platforms has had major impact on the
implementation (e.g. the IO channel subsystem). We now have threads
(which requires me to put mutex locks everywhere) and we have lots of
other "goodies" that turned the simple and nice Tcl interpreter into a
complex beast.

And since I am an API purist, I am also seriously concerned about the
way the Tcl API evolved. The core set of commands is IMHO not well
designed and getting more and more inconsistent. Note, I do not argue
against John Ousterhout or Scriptics here. They have to earn money to
keep the business running and so I can understand that they have to do
things that turn Tcl into what it is now. So what they are doing is
probably OK from that perspective.

If I were to start again, I would probably not choose Tcl anymore.
Today, we have lots of good user interface toolkits around. And Tk did
not evolve for years (except the addition of three dialogs or so) and
it shows. Tk is becomming less an argument for using Tcl. The Tcl
community also failed to come up with a workable solution to package
and distribute extensions. Yes, there are lots of extensions but most
of them are not worth the time it takes to download them since they
are outdated, not maintained, will not work with your Tcl version, are
ugly to install. I stopped to look for good Tcl extensions about three
years ago.

Eddie> I suppose the point of this message is to wonder if anyone else
Eddie> has thought about using Scotty from something other than TCL.

There was a phase where I tried to have the fastest API and I
streamlined internal data structures very much. Now I am going back to
give up some speed but to have good reusable components that may work
in multiple environments. Frank Strauss has done a great job with his
libsmi implementation, an embeddable C library that gives you access
to MIB data. This library will replace the current MIB parser in the
scotty package. But libsmi is also being used by other applications
such as the upcoming tcpdump 3.5 or gxsnmp. This will make it much
easier to use lots of different SNMP tools since they all share the
same common set of MIBs and they agree on what they understand and
what not.

In the longer term, I would also like to separate the SNMP protocol
engine from the script interpreter. This allows multiple interpreters
to share the same SNMP protocol engine, which has serious benefits
when you have lots of interpreters around and you are using SNMPv3
(since you can now share security related state information). Sure, it
will slow down the response times a bit, but this seems to be
acceptable these days. What is needed for this to work is a "manager
extensibility" protocol between the SNMP agent and the script
interpreter.

If these modules were in place, then it would be easier to design and
implement APIs for other scripting languages. As I said, I consider
API design very important. Python would be a serious candidate - but I
have never looked into the details of the Python implementation yet.

Unfortunately, I don't have the time to do all this. But if someone is
looking for a good project to work on, then I have lots of ideas...

[Sorry for the length of this email.]

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

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



This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 15:27:33 MET