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

----

[Category Package], subset [Tcllib]