In this issue, I'd like to continue this discussion. Basically, it would be good to have some well-designed and easy-to-use extension points that allows binding developers to provide programmatic extensions for devices that cannot be easily handled by the core binding.
Suggestion:
Discovery: Chain of responsibility, each extension decides on its own whether it wants to take care of a specific device. If an extension cannot take care of a device, it just passes it on to the next extension (and so on...). Advantage: Each extension can flexibly decide on its own whether its responsible. An extension could even take influence on the execution order by modifying the chain (e.g. an extension could decide to let other extensions try first if its unsure and run again at the end). Also, the order could be made user-configureable. As a default, I think alphabetically or the order of installation would make sense. Anyhow, of course the generic discovery handler should always run at the very end. The discovery service of the main binding (this one) has to resolve somehow all extension discovery handlers.
Extensions should define their own ThingTypeUIDs and put those within the discovery, so I hope ThingHandlerFactory will be resolved correctly out of the box.
State/Command handling: Developers could either extend BluetoothDeviceHandler and/or ServiceHandler or even implement BaseThingHandler and ChannelHandler/BluetoothSmartDeviceListener on their own. I think first option will be the more common one.
In this issue, I'd like to continue this discussion. Basically, it would be good to have some well-designed and easy-to-use extension points that allows binding developers to provide programmatic extensions for devices that cannot be easily handled by the core binding.
Suggestion:
BluetoothDeviceHandlerand/orServiceHandleror even implementBaseThingHandlerandChannelHandler/BluetoothSmartDeviceListeneron their own. I think first option will be the more common one.