Lars H, 2011-04-01: hubs is a package for communication between Tcl processes, that I started writing several years ago, but (so far) haven't gotten around to completing. I'm making the code as-is available however, since one feature — the hubs remote interp — that got finished seems like it could be utilised within a GSoC project.
The main source for hubs is
http://abel.math.umu.se/~lars/tcl/hubs.dtx
and the documentation that exists is
http://abel.math.umu.se/~lars/tcl/hubs.pdf
Hubs remote interp is a wikification of Section 8 of these. Previous sections have more information on specific protocols and interfaces in the system. The wire protocol (how messages are encoded for transmission over a channel) is also explained here on this wiki, in the "Wire Protocol" section of Tool Protocol Language.
AK - 2011-04-01 15:31:50
hubs seems to have a bit of similarity to Python's fabric . Although that is, AFAIK, only SSH based, using a pure-python implementation of SSH called paramiko . Tcl might have the foundation for that around already, in SteveL's cryptkit for cryptlib, although that foundation is binary.
Lars H, 2011-04-02: The idea of a Tcl equivalent of paramiko is listed in Library Ideas, and was (by reference) included in the 2009 list of GSoC ideas. Maybe it should be fleshed out for the 2011 list as well? Maybe a bit late for this year, however…
I first thought of comm when seeing this new page, however after reading I realized that comm is much more low-level. I have not yet dug deep enough into the hubs docs to see if my idea of comm possibly being usable as transport by hub has merit at all.
On a last note, I am interested in this and will try to keep up, because this might be a suitable foundation for something like a distributed build system similar to buildbot or Jenkins (aka Hudson ).
AK - 2011-04-01 18:39:00
Regarding comm "reading" in the previous comment refered to the wiki page. Now that I am actually in the hubs documentation I find that the relationship is completely reversed. hubs is low-level, comm is high-level, and this is addressed at the very beginning, in the overview. My oops.
Lars H: Well, there are both higher and lower level parts in it. For example, the "bulletin" subsystem is probably higher level than comm. The named pipe subsystem is on the other hand mucking about in the lower levels.
APN Folks interested in this might also consider m2. I was in the process of evaluating that versus comm for a home brew project. Now seems like I should add hubs to that list.