Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

this sort of response misses the point, and misunderstands the mechanism.
the plumber doesn't pass the file around, it passes a message around,
usually with a pointer (path) to the file. here's a direct link
http://www.plan9.bell-labs.com/magic/man2html/4/plumber
the literal plumber however isn't even the point. the point is that plumber
is an example of a file server which routes messages.

also, there is a long tradition in plan 9 of using file servers for messaging.
there are many more "virtual" file servers than there are disk file servers.
this avoids having to invent new address families. (and getting permission
from the kernel, libc, etc. to add them.) plan 9 uses regular 9p. network
transparency may be accomplished the same way as on-disk file systems. and
if one wants to see plumb messages on the edit port, just "cat /mnt/plumb/edit".
cat will block until a message arrives, display it and repeat. i don't need
a special plumbcat program.

whatever happened to the idea that "everything is a file"?

don't get me wrong, i wasn't saying the plumber solved this problem, i
just think it solves a similar problem. and it's worth considering if
some of the mechanism might be right for this problem.

there are a few reasons this is never a problem on plan 9
1. private namespaces. each user has his own set of private namespaces.
users don't interfere with one another.
2. on a shared machine, the user imports the plumber from their terminal,
so if they plumb a pdf, the viewer starts on the terminal.