Comment 11 for bug 311258

Hi Robin

Really good to see some information about this. My thoughts on this at the moment are that zeroconf:/ should be a subset of network:/ - on my machine zeroconf:/ does absolutely nothing anyway (may just be my machine, who knows ?). Additionally it seems confusing/duplication to have both "Network" and "Network Services", rather than just "Network".

I'm not sure why zeroconf:/ is limited in KDE to the mentioned services, it seems at-odds with the intention of any zeroconf enabled appliance to broadcast where it is on the network and what they do. For instance, I'd expect my TV could say over zeroconf 'Hi I'm a TV, I'm at this IP address and this is what I can do". It's then up to KDE to stream digital video to it.

From a client (Dolphin / Konq) point of view, any broadcasting services that it discovers and lists should be linked to the various applications that know how to handle that service. This would be in the same vein as a mimetype being linked to an application e.g text/plain being linked to Kate. Activating a found service would either prompt for a handler application or if one is already set, open that application. Dolphin then just hands off to the application and it deals with action.

For instance, my Airport Express broadcasts a ".airport" a ".raop" and a ".sleep_proxy". I have no idea what the latter is but the former could tell Amarok, for instance, that there is a broadcasting AP on the network and that it can accept music streamed using RAOP, much like iTunes streams music to an AP (there are various alternate clients around that can do this). Amarok already finds DAAP services via kdnssd so this kind of thing can be done.

Similarly, a ".ssh" service would open Konsole with a prompt to log in at the IP supplied, an http service would launch the default browser, and so-on.

Hope that helps as a use case/example.