[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 [http://docs.fabfile.org/en/1.0.1/index.html%|%fabric]. Although that is, AFAIK, only SSH based, using a pure-python implementation of SSH called [http://www.lag.net/paramiko/%|%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 [http://trac.buildbot.net/%|%buildbot] or [http://jenkins-ci.org/%|%Jenkins] (aka [http://hudson-ci.org/%|%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. <>Interprocess Communication