Re: [9fans] plan9port: acme remoting

[Ole-Hjalmar Kristensen <ole.hjalmar.kristensen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6050 bytes --]

Very interesting. In the past, I have resorted to using a combination of
Sam/9term/plumber in similar scenarios, but I really prefer Acme. At the
moment I'm running Acme over X11, since I'm constrained to using Windows on
the desktop, and I've got a working X server, but no Acme on Windows.
Anyone got plan9port to work under Cygwin?

On Mon, Jan 4, 2021 at 5:41 AM marius a. eriksen <marius@monkey.org> wrote:

> Lately, I have needed to do a great deal of my work on remote servers.
> It's been difficult to do this with acme. Previously, I have attempted to
> run acme entirely remotely, and then attach to a local devdraw instance
> <https://github.com/mariusae/devdrawserver>. This works okay, but also
> has many drawbacks, among which: (1) it's not economical with networking,
> and so not great for high latency or otherwise poor connections; (2) it's
> not resilient to connection disconnects; (3) often I want access to local
> resources too.
>
> I built an experimental remoting layer in acme to see how far I could get
> in recreating a modern "remoting" experience with acme. Since acme itself,
> of course, is designed around a bunch of 9p servers, this turned out to be
> fairly easy to do, and the resulting experience is nearly transparent.
>
> A remote may be attached to one or more path prefixes. These are similar
> to mount points in a file system. Thus, if the prefix /home/meriksen is
> attached to the remote "dev", then any file with this prefix is transparely
> fetched from the dev. Similarly, when commands are run from any directory
> with this prefix, the command is transparently run on the remote. The
> command is run in an environment that includes the acme and plumber 9p
> servers (forwarded from the local host), and so even acme programs just
> work. For example, if you run 'win' from a directory that is attached to a
> remote, 'win' is run on the remote host, but it accesses the acme 9p file
> tree (which is forwarded from the local acme) and creates its window and
> interacts with acme. It "just works". (I regularly run other programs like
> this too, e.g., acme-lsp, which uses the plumber to coordinate interaction).
>
> The design of the feature is quite simple: a new program, acmesrv
> <https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme/acmesrv> is
> run by acme (through ssh) on the remote host. Acme becomes a client of
> acmesrv, through which all further interaction is facilitated. Acmesrv
> itself is really just a 9p multiplexer: the local acme program exports the
> acme and plumber 9p servers; acmesrv provides two new 9p servers (exportfs
> and cmdfs) that gives the local acme access to the remote's file system
> (exportfs) and to run commands (cmdfs).
>
> The local acme manages a session for each remote, and properly deals with
> session disconnect/reconnect, etc. Thus, poor network conditions and
> disconnects are easily supported. Since acme's file handling is anyway
> stateless (the file is not kept open during editing), file state is easily
> maintained through disconnect-reconnect cycles.
>
> There are some synchronous code paths in acme, and these may cause
> temporary freezes when using remoting. For example, when acme queries for
> the existence of a file (stat), this blocks UI updates in acme. On session
> establishment (e.g., the first time a file is accessed on a remote), this
> can cause additional delays, since the file cannot be queried before first
> establishing a new session. I've not found this to be a big deal.
>
> This has been my "daily driver" for about a month at this point, and
> overall I'm very happy with the experience. It creates a nearly transparent
> experience editing remote files, and retains most of acme's functionality
> in remote settings as well. I never hesitate to shut my laptop lid while in
> the middle of a project. Most things just work. There are wrinkles, of
> course, and there are some sharp edges in this (experimental)
> implementation, but, to me, this provides really very useful functionality
> that lets me use acme in more challenging environments. (Not to mention
> that this means I can use a beefy remote host for heavy lifting.)
>
> In case this would be useful to anyone else, this version of acme resides
> in my plan9port tree on github
> <https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme>.
> (Currently, these diffs: 1
> <https://github.com/mariusae/plan9port/commit/dd56712c9d09fc89e8cb0e0b2ead42e1d52698cd#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
> 2
> <https://github.com/mariusae/plan9port/commit/a74049761a902a88502c9dfd3acd3f97591073d5#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
> 3
> <https://github.com/mariusae/plan9port/commit/edeba6c4cb652f99d4de79d151fd94b8eea7988f#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>,
> 4
> <https://github.com/mariusae/plan9port/commit/2fa8e435b6fedb7914bb6a2d7e1f48bba784ccdb#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>
> .)
>
> -m.
>
> (And of course, I realize that this approach goes against the spirit of
> acme and plan9 -- acmesrv here is recreating a very specific slice of
> functionality that could be recreated by standard means if we had real
> filesystems. But we don't live in that world, and this is immensely useful
> to me.)
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-M1347b1d8513480d11627e4eb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6731 bytes --]