RE: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments
My first thoughts are that this seems to be a very well-reasoned and well-presented proposal. Its excellent how you have presented the reasons for your decisions and I think I agree with all of them. I don’t think you’ve actually published the interface definition though, the document you linked to only contains your notes… J I particularly like the way you have presented the use cases and kept the proposal to the minimum necessary to meet those use cases.
With ICameraV2, one area in particular that I’ve noticed people having issues with is accessing the ImageArray. It would be useful if the proposal could be very clear about data ordering within the array and how this is accessed from various languages, preferably with code snippets. Good candidates are VBScript, Jscript, C# and VB.NET which covers access both from COM and within the .NET Common Language Runtime. I’m sure the community will be happy to help with this if you aren’t familiar with all the languages.
Once you publish your actual interface proposal, I’ll give more feedback.
Please find below my initial draft for a new ASCOM interface for controlling video cameras:
Your comments are highly appreciated!
Tom, to add to Hristo’s reply, people often get excited about the features of a particular device when discussing ASCOM interfaces. “But if it is designed like that, my XXX device won’t be able to use its ZZZ feature”. It would be a mistake to let an interface design be driven by the capabilities of any one device. In truth, you WILL be able to use the features of your device, but that will be a part of your specific driver and not necessarily part of the interface. Often, with a bit of imagination, a device’s bells and whistles can be used to great effect within its specific driver, without having to include those features in the interface design.
It is a difficult line between including enough features to be useful while keeping the interface device agnostic and lightweight. What is important is that the interface must be usable by any application _without knowledge of what device is actually connected_. In some cases, this means that some features of some devices will not be represented in the interface, this is especially true for devices with many features. This is a necessary part of the ASCOM philosophy, but it doesn’t mean you can’t use those features.
ASCOM has the specific goal of making it possible for applications to treat all devices the same (or as similarly as reasonably possible). Sometimes that goal is at odds with users who want to use all the bells and whistles of their kit interactively. Sometimes, an ASCOM driver isn’t the solution to your problem. If you need a highly specific application, then perhaps what you need is an app dedicated to your particular device. Again, this is a judgement call but most device vendors end up providing some sort of control application. A smart driver writer would produce a driver that can expose the generic ASCOM interface while also exposing a more device-specific API that app developers can talk to directly if they need more fine-grained control. The ASCOM architecture is very flexible and with a bit of imagination it is possible to come up with very full-featured solutions, the Gemini telescope driver is a great example of that.
I believe that Hristo is taking a balanced approach, he has a clear set of goals in mind, he has correctly understood the purpose of ASCOM, he has designed a well-considered interface and is being steadfast in resisting ‘creeping featurism’, but he is not closed to amendments where they are clearly justified. Please bear in mind that the justification “because my device has that feature” is insufficient justification for adding that feature to an ASCOM interface definition. An interface must represent all possible devices in a very general way. The balance to be struck is between keeping the interface generic and lightweight vs. including enough functionality to make the interface useful to observing applications. This compromise usually results in the inclusion of a number of Can* properties, but the further down that route one goes, the harder it becomes for an application to be developed to actually use the interface – the presumption must always be in favour of easy app development. In my view, it is better to start small, produce a few ‘real world’ implementations, discover what is actually needed based on the experience gained and then expand as needed. This design cycle is probably best done at least once before an interface is formally adopted.
I have no axe to grind here, because I don’t use video in my observing, I will not be writing any of the software and I have no vested interest in any application or technology, so in a sense the outcome has no bearing on me. But I do care about ASCOM and I know something about software engineering, so I offer the above opinions from a neutral architectural perspective.