Mike Edenfield wrote:
> I'm kinda stunned that your arguments against D-Bus seems to boil down
> to "just use 9p instead"
No, we're talking about very different concepts. D-Bus is essentially
an generic RPC mechanism (with an asychronous signalling facility).
So it allows calling procedures on remote objects sending signals
to listeners. IOW: fundamental concept behind GObject, QObject, etc
put onto distributed level (but much simpler than CORBA, etc).
On the other hand, 9P is essentially just a filesystem protocol
which is very well suited for synthetic filesystems. The latter
is the key point: synthetic filesystem.
Instead of calling procedures, you model objects into directories
and files and simply work with common filesystem operations.
This is the same idea as behind procfs or sysfs, but on an
distributed level.
Hopefully, we agree that procfs and sysfs are a simple and easy
approach for accessing many many kernel-internal data using
very standard filesystem operations. Now imagine we hadn't them,
but needed to use separate syscalls or netlink operations. Wouldn't
it be ugly ?
> given that plumber is a basic element of 9p and
> does essentially the same job D-Bus does.
No, plumber is an 9P-based service which does the message
broadcasting/routing to listeners (easily programmable by an
special-purpose language). Since it's based on 9P, it can be used
anywhere 9P is available, fully platform independent and network
agnostic.
http://plan9.bell-labs.com/sys/doc/plumb.html
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
