Discovering services

[Tako Schotanus]

Jamie McCracken wrote:
> Tako Schotanus wrote:
>
>> Maybe Jamie was right and I've misinterpreted what this thread was 
>> about: weren't we discussing how to solve the problem of getting the 
>> introspection data for unactivated services?
>>
>
> Nope you did not misinterpret this thread as a whole but there are 
> several issues (some of them arguably orthogonal).
>
> To sum up, here is my understanding:
>
> 1) You should not have to activate a service simply to get 
> introspection data.
Well but that depends on how you are goign to use this. Are you talking 
about just some kind of "documentation" you can read "off-line" or just 
an ease-of-use thing where introspection information is available for 
you in some files if you want to generate proxies in your IDE for example?

Ok, I can see that is useful, as long as we agree that activating the 
service and getting the same information from the introspect() functions 
is the "authoritative" way of doing it. And that the only way of getting 
that information when a service is not activated is looking up the files 
in whatever directory we think of. And those files might be there or 
they might not be (of course we could write a copy there the first time 
somebody calls an introspect() on an interface, but not sure if that is 
desirable).

Of course, now that I think about it, static languages might just do it 
the other way around, they might install those "introspect.xml" files 
and then whenever someone calls the introspect() function on an 
interface they might just return the contents of the respective .xml 
file. Well whatever works of course.

>
>
> 4) None of the interfaces should be dynamically changing at runtime 
> (if they are then its really bad programming practice as you will get 
> race conditions IE if you introspect an interface at runtime it could 
> have changed again before you have had a chance to call a method). 
> Thats not to say object instances wont change at runtime of course.
Well, I agree with you they shouldn't , but of course one of the things 
about agile languages is that they don't really ascribe to the same 
kinds of philosophies  that  more static/strict languages do.

But if this is how DBus interfaces should be designed that's okay with 
me, but is that described somewhere? Because I think we should make it 
obvious that interfaces are _not_ allowed to change. I'm not sure we 
should be making such a statement though, there might be use-cases, but 
yes it would mean that a static language would not be able to generate a 
proxy beforehand to communicate with such a service.

To be honest the only example that I can think of right now where 
full-dynamic interfaces would be nice to have is when you make a bridge 
to some other DBus-like service, like CORBA or something. If we would 
disallow dynamically generating interfaces we would not be able to make 
a bridge like that. But I recognize that is a really limited use-case.

PS: Don't you get the same race conditions when objects switch 
interfaces at runtime? Or just with objects disappearing?

-Tako