http://tcllib.sourceforge.net/doc/comm.html ---- Background: comm is a '''comm'''unication package. It essentially reimplements the [send] command known from [Tk] in terms of sockets. The original author is John Robert LoVerso. ---- Can one use comm as an exact replacement for send? Apparently not - using send, an interpreter registers itself and other Tk applications can query this registry to find out what interpreters are available. If you are just using comm, this is not the case. '''EE''': Well then, how does an application using comm find out who it can talk to? [AK]: There is a little nameserver application at http://www.purl.org/net/akupries/soft/pool/pkg_Pool_Net.html Application have to explicitly register. In that way '''comm''' is not as automatic as tk's [send]. [LV] I wonder if someone would be interested in writing a namesever that gets invoke from some sort of comm init function - I don't know how it would work , but surely it would be worth brainstorming. [AK] Tk's send is quite simpler, having the X server automatically available as a hub for communication. Ok, back to a comm nameserver. The implementation in pool (s.a.) uses a fixed port number and also implictly assumes that nameserver and applications are on the same host. IOW, local machine. Do we need more flexibility ? If yes, some sort of global configuration file is required so that clients are able to find the server whereever it is and on whatever port it is running. ---- [LV] In my mind, the ideal would be to do something similar to send - have comm transparently create an automatic hub for communication. One change I would make is to number the first interp registered as command #1, instead of just command. That might make distinguishing which command is available a bit more regular... [AK] Ok, the above implies a fixed port. As for naming the existing code asks for an explicit name and the server will reject it if that name is already registered. ... Automatic generation of a name is a tad more difficult. [[info nameofexecutable]] is not right, [[info script]] will give the wrong information too, ... Ok, our best bet is '''argv0''', right ? So that problem is essentially solved too. I believe we are now ready to submit a tcllib FR. (I just added 'comm' as category to the FR tracker of tcllib. It will auto-assign to me). ---- Anyone able to provide some simple example code showing use of comm? ---- [Category Package], subset [Tcllib]