Discovering services
Jamie McCracken
jamiemcc at blueyonder.co.uk
Thu Jul 6 10:15:54 PDT 2006
Tako Schotanus wrote:
> Jamie McCracken wrote:
>> Tako Schotanus wrote:
>>
>>>
>>> So what is the usecase where you would want to know what a
>>> non-activated service supports?
>>>
>>
>> If you are in a script editor or IDE style app and you are writing a
>> remote control script you might want to look at what services are
>> avilable and what interfaces/methods these have without activating
>> them all.
>>
> Yes, but that doesn't address the problem of services that have no fixed
> object tree like the example I gave about the printer manager. It is
> even conceivable that the interface(s) supported by those objects is not
> known.
>
> For an IDE or script editor it might be enough to just have an
> "activate" option on the non-active services. For something that will
> happen only at development time it would not be much of a hassle. Most
> likely you will only want to generate a proxy or something for that
> particular service or object, so having to perform an explicit action to
> make the introspection data available doesn't seem like a big problem.
>
> But yes, having to specifically activate the service will make it
> impossible to for example do a search for a specific object, interface
> or method/signal, but that doesn't seem like something we would really
> need anyway.
>
> At this moment I just can't see how we could put the introspection data
> in a file except for services whose object tree and interfaces are
> completely/mostly static.
Well for scripting you are only interested in static persistent *design
time* interfaces - it does not really make sense to use a runtime
dependent interface in a script that is dynamic or changing (unless of
course the script is coded to take this into account which would be very
rare!).
In COM, interfaces are pretty much set in stone and are not allowed to
change and I imagine the reason for this is so that scripting can be
done effectively.
Having *passive* introspection for design time interfaces would be cool
whilst *active* introspection like we have now can give both design and
runtime info.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
More information about the dbus
mailing list