Support exporting objects providing multiple interfaces

[Francis J. Lacoste]

The API infrastructure currently rely on the fact that we mix in all the interfaces provided by an object into an "aggregated" interface. For example, IProduct extends IBugTarget, IHasMilestones, etc.

But with the current architecture, if multiple interfaces are provided by the implementation, only one of them will be used for the entry representation.

The representation should really be the aggregation of all the exported interfaces of the objects.

[Jonathan Lange (jml)]

Is this the same bug as providing a way to export adapters of objects already provided by the API?

[Gary Poster (gary)]

Leonard's comment #1 on bug 512828 discusses one approach to this.

"Is this the same bug as providing a way to export adapters of objects already provided by the API?"

It's related, I think. Maybe if we solve a part of the adapter story, then that's enough for this use case.

AIUI, this bug is about looking at classes to determine what interfaces they expose, rather than looking at interfaces.

Salgado's current work is about being able to say that the webservice should merge interface X into interface Y, and adapt X to Y in order to get the implementation. That might address the underlying problem described in this bug report enough. In other words, if class C implements interfaces X and Y, and X is the one exposed, you could say that the webservice should extend the X interface with the Y interface bits. Whenever Y names were accessed, the code would adapt the context to Y, which would be a very fast no-op.

Is that good enough for this bug?

The adapter story also should provide the ability to show different perspectives of an object--different namespaces for attributes, effectively. We've talked about doing this, but it's more than this bug needs.

[Francis J. Lacoste (flacoste)]

> Salgado's current work is about being able to say that the webservice should merge interface X into interface Y,
> and adapt X to Y in order to get the implementation. That might address the underlying problem described in this
> bug report enough. In other words, if class C implements interfaces X and Y, and X is the one exposed, you could
> say that the webservice should extend the X interface with the Y interface bits. Whenever Y names were accessed,
> the code would adapt the context to Y, which would be a very fast no-op.

Yes, that's what I was after when I filed this bug.