9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "marius a. eriksen" <marius@monkey.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: [9fans] plan9port: acme remoting
Date: Sun, 3 Jan 2021 20:40:24 -0800	[thread overview]
Message-ID: <CAPtk8tt3=_SrdVTm7Qw86xxDMuegn6X7w9jLk1asjmq=qO556Q@mail.gmail.com> (raw)

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

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: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

             reply	other threads:[~2021-01-04  4:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-04  4:40 marius a. eriksen [this message]
2021-01-04 11:00 ` Ole-Hjalmar Kristensen
2021-01-04 11:43   ` Pouya Tafti
2021-01-04 12:58     ` Semyon Novikov
2021-01-05  3:01 ` Lyndon Nerenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPtk8tt3=_SrdVTm7Qw86xxDMuegn6X7w9jLk1asjmq=qO556Q@mail.gmail.com' \
    --to=marius@monkey.org \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).