How to introspect different versions of the same interface?

asked 2014-07-07 11:34:06 -0700

Jehan gravatar image

Currently some of the official AllJoyn interfaces implement a "Version" property to indicate the current revision on the interface. However, one BusAttachment can only know about one version. If an object A does introspection to discover what remote objects (B and C) implement, then A can only know about the methods/signals/properties implemented by the first object introspected, e.g.:

  • B implements interface “Intf” v1 which has method M1
  • C implements interface “Intf” v2 which has methods M1 and M2

A instrospects B first then C. A will know that both implement “Intf” but the definition of the interface will only contain M1 (A will not know about M2).

Inversely, if C is introspected first, A will not know that B doesn’t implement M2 (unless it knows that M2 is a v2-only method, but then A wouldn’t be doing introspection in the first place).

Is there a workaround that problem?

edit retag flag offensive close merge delete

2 answers

Sort by » oldest newest most voted

answered 2014-07-10 10:30:45 -0700

bspencer gravatar image

updated 2014-07-10 15:48:30 -0700

Having a version in the AllJoyn Service Frameworks is for an extra level of verification and for semantic changes on the applications that use a service. An AllJoyn Interface is a contract and it will not change from what it is today, but could be extended to add new methods. IE if the "v1" of an interface is a subset of what would exist in "v2" (when/if a v2 exists). The nature of the service frameworks is that you would not implement multiple version so the same service framework because the Interface does not change. You would support "v2" and, as such, the "v1" applications will still work, and the "v2" applications will have the increased ability to place a call to M2.

To directly answer your question, the Application/device should not implement a "v1", "v2", "vN" interface and would just implement the most recent interface. This would allow for a single Bus Object that implements the interface that can then be introspected. The work around is not never implement different/conflicting definitions of an AllJoyn Interface in an application.

If for example, there was an interface for Power and there was a method of powerDown in a "v1" interface that completely turns off the device. Then assume that the Power working group discusses and thinks that powerDown really should be to put the device into standby mode instead of full power down. The interface hasn't changed, but the semantic meaning of the service framework has changed. Therefor the Version property can be increases so that it provides the information that a remote application could have an awareness that the device would not power down completely. But at the end of the day nothing changes and everything still works.

AllJoyn Interfaces, once standardized through the AllSeen Alliance should not change the Interface but should extend it. Methods/Signals/Properties that are not valid as the Service Framework evolves would be deprecated and a new method added that extends the standardized Interface.

Edit 1:

Workaround now that the problem is clear that there are different devices implementing the same interface name but with one application/device extending the interface to add more methods/signals/properties. What is happening is that when you use the ProxyBusObject::IntrospectRemoteObject method call this is a helper function to generate the object that can speak to the other side. In the lower level code it will activate the interface that it introspects which basically caches the interface in the system and fixes it from being modified. The work around is to perform some work yourself and not activate the interface. IE make the request to get the Introspection XML and then parse the contents without activating the interface.

Edit 2:

After contemplating this issue the workaround is a lot of extra work that a developer can do and it does not address the core problem that you have raised about the ability to Version an interface. I have created a Jira on AllSeen ... (more)

edit flag offensive delete publish link more


The problem is the discovery/introspection. If A introspects B, "Intf" will only contains M1. If A _then_ introspects C, since "Intf", being already known by A (albeit the v1 version), will still only contains "M1" and no "M2".

Jehan ( 2014-07-10 11:50:25 -0700 )edit

Updated answer to add a work around now that the problem is clear that B and C are different applications and not just different Object Paths.

bspencer ( 2014-07-10 13:04:27 -0700 )edit

Updated answer to add the Jira to track a change to the core software.

bspencer ( 2014-07-10 15:49:00 -0700 )edit

answered 2014-07-16 15:10:20 -0700

Ashutosh Aggarwal gravatar image

I wanted to share different backwards compatibility mechanisms that are possible in the AJ system. We definitely need to account for the scenario where an interface initially implemented as v1 adds new functionality; it is not imminent but we need to deprecate functionality as well. For the options highlighted below, I assume the underlying introspection issue as highlighted in this thread is fixed within the scope of the JIRA ticket.

Interface versioning and backwards compatibility options are:

  1. AJ service interface adds VersionMap property that indicates what version #s from 1 until the latest release N (note that version=N) are implemented by the service. Any client that wants to invoke the service finds the largest version that is supported by the service and the client. The set of versions supported by service is given by the VersionMap.

  2. AJ service interface adds MinimumSupportedVersion in addition to Version. This indicates to the client that service implements all the versions in the set from Minimum Supported Version..Version. This implies that service has deprecated all the functionality prior to MinimumSupportedVersion.

  3. We add version in the interface name itself (as mentioned in the ASACORE-688). This provides a workaround for the introspection issue as well. While this provides unique functionality mapping to an interface name in time, this adds interface management workload e.g. permissions management being designed as part of Security 2.0 will need to be carried forth interface from v1 to v2 if a new member was added but all existing members were retained.

Looking for feedback from members.

edit flag offensive delete publish link more
Login/Signup to Answer

Question Tools

1 follower


Asked: 2014-07-07 11:34:06 -0700

Seen: 216 times

Last updated: Jul 16 '14