From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.help Subject: Re: Temporary notes in Emacs buffers? Date: Mon, 6 Jan 2020 09:18:56 -0500 Message-ID: References: <87zhfecbpt.fsf@mbork.pl> <87sgl0osts.fsf@web.de> <65742f83-393a-4df2-9562-7c500b40adcd@default> <87a777ydnh.fsf@web.de> <73dc0d0e-f208-4169-a70d-f2f17994a4f4@default> <87o8vmlkdq.fsf@web.de> <958f5d11-5d36-4627-a106-11b47b3e9c79@default> <87png2ed33.fsf@web.de> <1d24a14a-b38a-4a66-b6d0-cca8aff7dacc@default> <87mub573g5.fsf@web.de> <8736cvbu8f.fsf@web.de> <2e0e01a2-d945-4492-94ec-eb903764a7ef@default> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="167802"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Michael Heerdegen , Help Gnu Emacs mailing list To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jan 06 15:19:44 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ioTEO-000hYP-5M for geh-help-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 15:19:44 +0100 Original-Received: from localhost ([::1]:52330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioTEM-0000Vg-R7 for geh-help-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 09:19:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33776) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioTDr-0000VE-Ow for help-gnu-emacs@gnu.org; Mon, 06 Jan 2020 09:19:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioTDq-0003I6-HJ for help-gnu-emacs@gnu.org; Mon, 06 Jan 2020 09:19:11 -0500 Original-Received: from mail-lj1-f174.google.com ([209.85.208.174]:34899) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ioTDq-0003Gv-A9 for help-gnu-emacs@gnu.org; Mon, 06 Jan 2020 09:19:10 -0500 Original-Received: by mail-lj1-f174.google.com with SMTP id j1so43693994lja.2 for ; Mon, 06 Jan 2020 06:19:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WxSttHF7PRJ9sgpIUoZaFQeDZZtydq7FNGtfZDexsGc=; b=B4qwUXj9cQc4z915u5nPz8MdC7YSAJWaNYXX3rXiQu83aGNo9OW7mq6m5dd1QL/n0U khW1xbCmH2qrDNqGP/F1NrbHAwEOiROTaJu09tyZuGloMCAIGUsNP4oG+U4MUebxyljq OOeWqNjWNhK1RTD9FeJxinDfmXVg3vAQz5JuB4aWJUwnxa0qQrfzS2MSCKPyEfT969aO BA39p0+FrqM8jUZ73QBxo50PbDllIHo7L00meEdxoVCQRpAJUtkK6fLNuMRN6eq7NhSV VtczVBOc/p8XCQGOcxIoxxk/FDM4yzktgRfSMM84QcQr+v7/gXtZkylVWb/woAcxaGe7 X9tQ== X-Gm-Message-State: APjAAAXYUQS0o5hQ8LYReSuZABrl8Ne2xQZRu38mEZYD7nCe1mDkybdb Q2l8+ARGToIjWqYESni247UupM23dUlJp58t/fc= X-Google-Smtp-Source: APXvYqy8Vgo5LcGy4lAq2ddcHoqIVX4k+EPSH4x77qVMC09thgJu9IoMCbasTUrT9xf5dcaT/akfsUxRmqLDzsd2WwU= X-Received: by 2002:a2e:b044:: with SMTP id d4mr51906763ljl.158.1578320348315; Mon, 06 Jan 2020 06:19:08 -0800 (PST) In-Reply-To: <2e0e01a2-d945-4492-94ec-eb903764a7ef@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.208.174 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:122173 Archived-At: On Sat, Jan 4, 2020 at 11:05 AM Drew Adams 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