D-Bus and Bonjour service discovery

[Tim Wilkinson]

I guess I'm speaking conceptually - obviously you don't run anything  
on the bus since it is, when all said and done, a bit of damp string  
with a couple of cans at the end (only more hi-tech) :-)

I saw Jamie's note go by and yes that's basically what I'm driving at  
here - and since dbus already have the ability to connect services  
across machines (via good old tcp) then its more about managing  
service discovery in such an environment.  As I've said, mostly I'm  
trying to get a handle on the usefulness of the ideas rather than the  
implementation of the ideas - I have no doubt it can be implemented  
and probably a cooperating set of demons exchanging service  
information via Bonjour is the way to go, though there are other  
options such as DHTs, centralized registration similar to DHCP or DNS  
(clearly the easiest to implement), or even something as horrible as  
a master/slave vote base manager thing (similar to Microsoft's local  
networking stuff).  I'm in favor of a Bonjour based implementation  
primarily because my experiences with the protocol have been very  
positive.

As for audio - yeah, well I knew that was a bad example the moment I  
wrote it :-) However, the concept I was driving (poorly) at was the  
potential for dbus to allow you to use the same inter-app protocol  
between apps on different machines - not necessarily without  
realizing this (because after all they have different environmental  
characteristic) but at least without having to do it all a different  
way.  Better examples might be collaborative applications, sharing a  
scanner, programming a DVR, operating a home Zigbee mesh, managing a  
WiFi box or NAT, compiler or render farms, etc. - essentially  
anything you have one one machine you want to use form another  
(ignoring anything with realtime properties for the moment).

All these Linux based boxes on my network not speaking to each other  
is just ... well .. wrong ...

Tim

On Nov 22, 2006, at 9:49 PM, Havoc Pennington wrote:

> Hi,
>
> Tim Wilkinson wrote:
>> Instead what I was proposing was the addition of a third default  
>> bus - call it the 'lan bus' or 'bonjour bus' if you want.  Its  
>> purpose in life is to allow clients to make services available  
>> between machines rather than just within one machine (using the  
>> other buses).
>
> It's not clear to me what "lan bus" means, though. You can't just  
> have a bus "on the lan" it has to run on some machine. Jamie  
> suggested one thing it might mean, a bus on each machine with  
> something like bonjour for discovering available machines. That  
> might be of interest to experiment with.
>
>> It seems sort of silly when you look at a networked home and see  
>> just how much Linux is kicking about in it (various network boxes,  
>> Tivos, Cellphones,  NAS, media servers, etc.) and then realize  
>> that there's no standard way to plug these pieces together.  Sure,  
>> there are lots of other ways to do it, but that makes talking to  
>> an audio device on your local box different from talking to one on  
>> a set of speakers on a remote device.  At least in a LAN scenario,  
>> and with a sprinkling of dbus magic, I don't see why it has to be  
>> that way.
>
> There are very good reasons why different kinds of IPC exist. Audio  
> is a great example - network audio (different from streaming audio)  
> is very hard, and from what I've heard about it, barely feasible  
> with a highly-tuned domain-specific protocol. It's probably not  
> possible to make it work with dbus as the protocol.
>
> Havoc
>