rjkroege/edwood

Remote Edwood Question

knusbaum opened this issue · 5 comments

knusbaum commented

Hi, @rjkroege

I'm wondering if there's a way to support running edwood remotely over ssh.

I've found this set of programs (https://github.com/4ad/mgk.ro/tree/master/cmd/plan9) which forwards a devdraw connection and sets DRAWTERM to a proxy on the other side. The proxy needs the following patch to fix the io order to work at all with edwood. Oddly, it will work just fine out of the box with acme. I think it maybe has to do with the different semantics for pipe(2) in plan9, but I'm not sure.

diff --git a/cmd/plan9/devdraw-proxy/proxy.go b/cmd/plan9/devdraw-proxy/proxy.go
index ac8b295..0cdedae 100644
--- a/cmd/plan9/devdraw-proxy/proxy.go
+++ b/cmd/plan9/devdraw-proxy/proxy.go
@@ -51,8 +51,8 @@ func main() {
 	if err != nil {
 		log.Fatal(err)
 	}
-	go proxy(os.Stdin, conn)
-	proxy(conn, os.Stdout)
+	go proxy(conn, os.Stdin)
+	proxy(os.Stdout, conn)
 }
 
 func proxy(dst io.Writer, src io.Reader) {

With acme, the UI shows up and seems to work. The above fix allows edwood to do RPC (I can see the calls going and responses coming back), but the UI remains blank.

Netcat also works fine as a proxy for acme but edwood behaves like it does with the devdraw-proxy program.

I don't think the bug is in netcat or the proxy, so my guess is 9fans.net/go or edwood or even go are doing something differently with file descriptors that doesn't work for edwood/devdraw.

Wondering if you have managed running edwood over ssh and if so, how.

rjkroege commented

I've found this set of programs
(https://github.com/4ad/mgk.ro/tree/master/cmd/plan9) which forwards a
devdraw connection and sets DRAWTERM to a proxy on the other side.
...
Wondering if you have managed running edwood over ssh and if so, how.

I've used the devdraw proxy with Acme. I was always disappointed with
the results because the latency of my ssh connections made it hard to
chord, doubleclick or select. I think that while the proxy is technically neat, it puts the ssh latency in the wrong place from a UX viewpoint.

I've never executed Edwood over a proxy. After I stopped using
the devdraw proxy, I've always run Acme or Edwood locally and done some
variation of

  • using sshfs to mount the source tree to the client
  • using rsync to sync the source tree to the client and then slurp pulling updates to the server

I combine this with using import to expose Edwood/Acme and the plumber to the server so that tools like B, win, etc. work server side. There are two problems with this approach:

  • middle click actions run on the client
  • 9p connections over ssh aren't very resilient to network interruption

The first one seems possible to do in Edwood: an external Edwood client could
receive "exec" messages and connect back to Edwood over the filesystem
in a similar way as the existing Edwood fork(2) copy connects back to
deliver middle-click results. Maybe this works already.

The second seems desirable but a separate project.

With acme , the UI shows up and seems to work. The above fix allows edwood
to do RPC (I can see the calls going and responses coming back), but the UI
remains blank.

Netcat also works fine as a proxy for acme but edwood behaves like it
does with the devdraw-proxy program.

You have raised an odd bug here. I have no idea why this is happening.
I'll have a look eventually but if it's complicated, it might take me a while
to get around to fixing this. (Patches always welcome.)

So, I see several issues here:

  • make Edwood work with the devdraw proxy
  • figure out how / make possible middle-click execution run on a remote
  • improve resilience of 9p connections over intermittent connections. (I recall that p@ wrote something to do this. I should go find.)

I should probably provide a howto and scripts needed to do the import dance.

knusbaum commented

@rjkroege Thanks for the info!

I've been doing something similar to your setup (local Edwood, importing remote filesystem using my 9p tools) but was hoping to find a way to have a smoother experience.

I'm planning to do some experimenting with this. To solve flaky network connections, 9front uses aan(8). It would be great to be able to tunnel 9p over something like that on *nix systems.

It would also be cool to split edwood up into a client/server sort of like sam (I think it calls the components host and terminal). That would solve the first 2 problems, and if we could pipe the client/server connection over aan or mosh or some such thing, that would solve problem 3.

rjkroege commented

I looked at your CL and am increasingly enthusiastic about getting something like this functionality landed. Are you willing to work together on upstreaming? There are a few things that I'd like to see changed.

knusbaum commented

Hey, @rjkroege. Sorry I haven't had any time to look at this over the past few months.
I'm still interested in working on this and hoping to find some time over the next couple months.

rjkroege commented

Great. I still think that something like this is a neat feature so I'll look forward to you having some time.