Discovering services

[Havoc Pennington]

Will Stephenson wrote:
> On Tuesday 04 July 2006 22:39, Jamie McCracken wrote:
>> Havoc Pennington wrote:
>>> If you need this, I think we'd have to look instead at some way to
>>> install the introspect information in files. But, that's a pretty large
>>> project and adds a fair bit of complexity.
> 
> It's a project that is seriously needed.  For safety and pleasure whilst 
> coding, one should use automatically generated dbus stubs and skeletons, so 
> for cross project interaction over dbus installed introspect XML is a must.
> 
> Either a) installing to $prefix/include along with the application's headers 
> (ugh) or b) installing elsewhere and extending pkg-config to locate them 
> would do it, I think.

We have to approach this in an effective way...

Right now probably the most popular dbus APIs are 1) the lowlevel "by 
hand" one and 2) Python, and neither one of those has the static 
interface information at all, nor would they benefit if other apps had 
it... so I think we could specify "the idl files get installed in xyz 
location" all day long with little or no effect in this world.

Given this, I think starting from an installed files spec is probably 
sort of backward. The way I'd approach this is to start from the 
bindings tools to be sure they generate the required files. Once it's as 
easy to create the files as not, people will do it.

In the end I think it's sort of a religious topic, like static vs. 
dynamic programming languages. Some apps using some bindings will never 
bother to generate static interface info.

As a protocol and lowlevel library dbus does not have a lot to say about 
it either way; it's more something that'll get decided on the bindings 
level.

Right now some important bindings (e.g. glib) don't even generate 
_dynamic_ introspection info I don't think...

I personally prefer the I believe DCOP/Java-like approach of generating 
the IDL from the code, rather than the COM/CORBA-like approach of 
generating the code from the IDL. But each binding can really pick their 
own poison here. I originally wanted glib to be the dcop/java way but 
I've lost track of whether it is.

In the end it's totally academic unless someone here is going to work on 
a patch...

>> Another thing missing (unless I have missed it!) in the Dbus introspect
>> format is english descriptions of the methods suitable for display in an
>> IDE/ script editor - think glib property descriptions and VBA's ability
>> to display english descriptions on remote COM method calls in its IDE
>> (.Net also has this ability too).
> 
> Fully agree, I've seen several interesting dcop applications grow out of 
> people playing with the command line client and discovering the potential.  
> This is made much easier by self-documenting over the bus.

This has been discussed and a rough plan outlined several times, but no 
patches yet.

Havoc