Allow to add Methods and Signals to specific interfaces on the DSB Bridge

[dotMorten]

Currently signals and methods can only be added to a single "MainInterface" interface, however properties can be added to their own interfaces. This makes it completely impossible to use the DSB to follow specific interface designs.

Please make it so signals and methods can join the properties in their rightful places by allowing us to specify the object path and interface name for them.

[dotMorten]

/CC @zhuridartem

[zhuridartem]

Thank you for the feedback. This is a known current limitation.
To unblock anybody for adding signals and methods to a specific interface: please follow similar model as LSF and Control Panel special handler in BridgeRT.

DSB was designed to project a generic device to an AllJoyn representation. Current implementation has a limitation for projecting to a specific AllJoyn service standard. To enable such mapping, DSB has a concept of a Special Handlers. It does require adding code that does the projection in the DSB though. LSF and Control Panel services have been implemented in the DSB's BridgeRT as an example.

[dotMorten]

@zhuridartem If I were to rewrite the DSB so a IDeviceAdapter instead has an IVector<IDeviceBusObjects> which in turn has list of IVector<IDeviceInterfaces> which has a collection of properties, methods and signals, would you be open for changing the DSB here? If not, I'll probably create my own (competing 😄) version
I can see a huge benefit of this for especially .NET developers, because it becomes really easy to implement any interface and group them so they follow the specifications.

DSB was designed to project a generic device to an AllJoyn representation.

I don't know what this means. You can't implement any alljoyn representation which is what I would think "generic" means.
You currently have properties on any number of interfaces, and methods and signals on MainInterface only. This is extremely inconsistent.

To unblock anybody for adding signals and methods to a specific interface: please follow similar model as LSF and Control Panel special handler in BridgeRT.

So what you're saying: Just write it in C++ against the Alljoyn_C library? I took a look at the LSF implementation. It's an ridiculous amount of tedious code that I could cut into a fraction with my approach, not to mention you'll be inviting a huge amount of C# developers to the AllJoyn party. The bridge is so close to function from the C# end, and fairly easy to work with.

[dotMorten]

If anyone is interested, just published my modified (read: much improved 😄) DSB to nuget: https://www.nuget.org/packages/dotMorten.AllJoyn.DSB/

Now you can create bridge devices in just a few lines of code, like this HAE device: https://github.com/dotMorten/AlljoynDSB/blob/dev/src/AllJoyn.Dsb.MockDevices/MockCurrentTemperatureDevice.cs#L58-L67

This meant I could delete a HUGE amount of code from all my various DSB services and just reference this nuget instead.

Main benefits:

• You can implement multiple bus objects with multiple interfaces. Each interface can have properties, methods and signals, so you can finally match the alljoyn specifications.
• MainInterface is finally gone
• Much easier programming pattern for C# devs
• The DSB now allows you to set a proper name for the DSB device itself. If you have multiple DSBs on your raspberry, they don't all have the same name.