[9fans] Plumber architecture question

[9fans] Plumber architecture question

[Ethan Gardener]

Every so often, I start wondering why the plumber isn't simpler.  Here's my simpler design:  There is no plumber.  Instead, `plumb` reads the plumbing files and acts accordingly.  To receive input from the plumber, programs post a pipe in /srv.  No need for a special-purpose filesystem.

It will break if multiple processes post the same pipe, the second process won't be able to create the pipe.  Isn't that a good thing?  Plumber behaviour is to send messages to all recipients, which has surprised me a few times when I wasn't quite alert.

It would also break my use case of separate plumber instances for separate activities; there is only one #s, but I don't think anyone does this other than me.  It can be done another way, with plumber rules to discriminate by directory, but that takes a bit more setup.  I would work if there could be multiple srv(3) filesystems, which I think would sometimes be useful for other tasks too.  To make this work, all the programs which currently address '#s/filename' would have to be changed to address the full path.  Then creation permission would control which of the srv filesystems gets the pipe.

Just musing on architecture.  Comments welcome.

--
2.1.3. Life with eternal upgrades

Re: [9fans] Plumber architecture question

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 157 bytes --]

Re: [9fans] Plumber architecture question

[Ethan Gardener]

On Sat, Jan 5, 2019, at 2:12 PM, erik quanstrom wrote:
> you need plumber so cpu can be transparent to plumbing.

Good point.  I think it could be done with multi-/srv, but I see one problem: you wouldn't want cpu to export all of /srv.  (Right?)  I think it could be dealt with by mounting a separate #s instance (for want of a better name) just for the plumber-replacement pipes.