Re: Temporary notes in Emacs buffers?

[John Yates <john@yates-sheets.org>]

On Sat, Jan 4, 2020 at 11:05 AM Drew Adams <drew.adams@oracle.com> wrote:
> > An approach not yet mentioned is including some form of
> > UUID as a file local variable.  In such a setting notes
> > indirect through a persistent UUID-to-path map.  A file
> > handler recognizes relevant operations on UUID annotated
> > and updates the map.  This might also include updating
> > the new copy's UUID to preserve uniqueness.
>
> My question about this is (still) how do you use
> `find-file' (or something else) to open a file
> for editing, given just the inode/UUID?
>
> Such a thing could be recorded in a bookmark,
> but how to use it, to get to the file, with
> Emacs?

This is rather half baked.  It combined ideas from Gnu arch and
Apollo Computer's distributed file system.  The common thread is
the idea of a UUID.

The Gnu arch DVCS embedded the UUID in the text of a file being
managed (essentially an elisp file local variable).  This was
crucial to supporting renaming.

An Apollo UUID contained the equivalent of the MAC address for
the node which first handed out that UUID.  UUIDs were used in
many ways and many APIs.  In particular the UUID replaced an
inode index.  This made the ID of a file container universal
rather than file system relative.  The equivalent of the inode
table was a persistent hash table indexed by UUID.

File lookup by UUID was not only supported but fundamental:
directories were mapping from names to UUIDs.

Simplified file open by UUID:

  First: attempt local open:
  * Probe local file system's hash table using UUID as key
  * If found return a local file connection

  Fallback: attempt remote open:
  * Extract MAC address from UUID
  * If self then return file-not-found
  * Use MAC address to talk to node that issued that UUID
  * Ask that node to open a file by UUID
  * Remote node performs only the local half of file open
  * If found return a cross-network remote file connection

  Otherwise return file-not-found

The above works up until one allows UUID identified objects to
migrate across nodes.  To support such use cases Apollo added a
redirection service.  The idea was that any node that allowed a
UUID containing its own MAC address to be exposed on another node
was responsible for tracking that UUID.  Persisting a foreign
UUID involved first obtaining permission from the source node's
redirection service.  This allowed the source node to record
whither its UUID had migrated.  With the redirection service in
place prior to probing the local file system's hash table for a
local UUID one would ask the redirection service whether the
presented UUID had been migrated.  If so the result was a
redirect status identifying the node now hosting that UUID.

If any of that makes sense then perhaps some of the ideas can
be turned into a design using a persistent UUID-to-path map to
associate notes to files identified by an embedded UUID.

/john