Hi all, while working on the initial browse API in Go, I also started thinking about how we could also clean up the Subscription API. I mentioned it before, I'm not happy with the current API, as I think it's far too complicated.
Not even I managed to simply use it and get things right the first time. Usually I start having a look at how we do things in the examples and start using that. This is usually a signal for me that the API could use some changes. Right now, given the pretty small amount of drivers supporting subscriptions, I doubt many people are actually using it right now and doing some radical changes here soudln't harm our users. And we did say: If we don't know about people's usage of something because they don't publicly talk about it, we shouldn't worry about it. So right now we allow creating subscription requests that contain a mixture of "periodic", "on-value-chang" and "alarms/events". From an implementation perspective these are completely different types of subscriptions. So providing this mixture-support will definitely complicate things. (I think right now most drivers will only support "on-value-change"). But then I started thinking: In which scenario would I develop an application that does such a mixed subscription request? I couldn't come up with a sensible scenario which couldn't be implemented by multiple subscriptions: one per each type. So I would propose to change the API in a way, that the SubscriptionRequestBuilder allows preparing 3 types of subscription requests. The part I never got right, was how we add callbacks to subsciptions. Currently it allows us to attach no/one/multiple handlers to subsets of fields of a subscription. But when would I need that in an application? Of course, multiple parts of an application could subscribe to different subsets of fields, but that would be something the driver should handle, and not the application. So I would propose to add a handler as argument to the "execute" method of the subscription request. I think this would make applications simpler, it would make the api more intuitive and it would help greatly clean up the implementations behind the request types. What do you think? Chris
