From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <dce581f9f73372f8cee6ab80c5c351da@plan9.bell-labs.com>
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Acme 3-1
In-Reply-To: <1aab927871041392cfbca0aa90236548@vitanuova.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Tue, 18 Feb 2003 08:38:55 -0500
Topicbox-Message-UUID: 67bd5b56-eacb-11e9-9e20-41e7f4b1d025

> i don't think the broadcast nature of plumbing is what's wanted in
> most cases, but perhaps others disagree?

when it happened, the consensus seemed to be (i was
watching from afar) that neither broadcast nor unicast
was really a perfect answer, but broadcast was easier
all around.  the plumber doesn't really know where
messages are coming from, so you'd have to add something
for that, and you'd have to add some way to change where
the unicasts were going.  some way to associate incoming
messages with outgoing fids.  it gets ugly quickly.

another possibility is to round-robin unicast
readers when you get the same message over and over
again, you would 3-click the same thing
multiple times to get it to appear in the right window.
this combined with a broadcast attribute would probably
work reasonably.  i'm still not sure -- there are rarely
times when i would actually use such functionality.

i just added

fn sam {
	if(~ $1 -*)
		exec /bin/sam $*
	@{
		rfork n
		plumber
		exec /bin/sam $*
	}
}

to my profile, which nicely fixes the one time when i
wish plumbing weren't there.  (i use sam instances
when i'm using a lot of the command language on a
fixed set of files, and literally never want to plumb
new files into the sams.)