On Fri, Jul 10, 2009 at 6:35 PM, Russ Cox <rsc@swtch.com> wrote:

> iosrv sounds neat.
>
> if you want a challenge, i would like to see the gui version,
> something along the lines of inferno's drawmux,
> which would be more work but also more broadly applicable.
> http://www.vitanuova.com/inferno/man/2/drawmux.html
>
> russ
>
> Thanks very much for the suggestion - and that is exactly the direction I
am planning to work in, following some needed improvements to the
fundamental implementation. (iosrv needs to be rewritten to be its own 9p fs
and not piggyback on exportfs, most importantly). Given the beauty of plan
9's data-agnostic approach, you can already do things like sending mouse
data through an iosrv pipe and binding that pipe on top of /dev/mouse to
control a remote graphical application. I have yet to study the issues in
detail but thanks to the 'consistent, agressive application' of the clean
file i/o abstraction throughout the Plan 9 system, I hope it will be
possible to make iosrv able to multiplex and make persistent any and every
application. A persistent, shared rio session is the goal, but no promises
on the delivery time for that feature.

One easy trick to make iosrv integrate better in its current form into the
GUI layer is to allow the rc sessions hosted 'inside' the iosrv to import
the /srv of the client machine, and then make use of the calling user's
plumber and wsys on their original machine. I'm still working on exploring
what exactly can be done with this thing!
--------
Iosrv can provide simple, basic functionality along the lines of gnu screen,
but also offers the ability to create custom i/o Hub setups. As an example
of doing more, here is a recipe for allowing your iosrv hosted shells to set
up an independent shared communication channel between them. The starting
assumption is that you have used the 'io' command as 'io iosession' to begin
an iosrv, then connected multiple clients to it using 'io iosession' and
those clients have created new rc subshells within the iosrv using the
inside-the-ioshell commands such as 'local 3' and 'remote 6'. From within
one of the attached shell sessions, issue commands to create new Hubs:

hub h27s0
hub h27o0
hub h28s0
cat </n/iosession/H27out0/data1 >/n/iosession/H28in0/data &

Now you have a persistent cat running between two new Hubs provided by
iosrv. To turn that into something useful, in all the attached clients you
will want to do:

hub h28o(current hub attach # here)
cat /n/iosession/H28out(attach #)/data1 &
bind /n/iosession/H27in0 /n/chat
echo 'hi everybody!' >/n/chat/data

Now you can send messages between the shells by echoing messages to
/n/chat/data and they will be printed to the other attached shells by their
cat of the output pipe running in the background. When new clients connect
and provide their own unique hub h28o# command, the cat of its output will
give them the full backlog, buffered by the iosrv.

I'm very interested in some feedback on the general idea of the Hub as an
extension of the pipe - the idea is that a Hub has multiple simultaneous
inputs and outputs and allows processes to connect and disconnect from it
freely as it is running. I am a relative newcomer to the world of UNIX and I
am interested in previous implementations of this type of functionality. I
wonder if I have wandered into the territory of STREAMS which I confess I
know by reputation only.

Mycroftiv