Discovering services

[Jamie McCracken]

Tako Schotanus wrote:
> 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.

yeah thats about right

> 
>>
>>
>> 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.

No that was just my opinion!

Dbus does not enforce interface integrity so they can be dynamic but in 
those cases you would not have file based introspection or it would be 
only a subset of the available data. From a scripting point of view, 
dynamically changing interfaces are too much of a problem to use 
effectively anyhow.



-- 
Mr Jamie McCracken
http://jamiemcc.livejournal.com/