Loading ...
Sorry, an error occurred while loading the content.

Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

Expand Messages
  • Bob Denny
    Was this Windows 8 Metro? -- Bob
    Message 1 of 85 , Apr 30, 2012
      Was this Windows 8 Metro? <joking here>

      -- Bob

      On Apr 28, 2012, at 19:10, "Tim Long" <Tim@...> wrote:

      > Ah now that’s interesting. On the first computer I used, the page background came out the exact same colour as the hyperlink
    • Tim Long
      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
      Message 85 of 85 , May 21, 2012

        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.



        Tim Long


        From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of tom@...
        Sent: 20 May 2012 19:32
        To: ASCOM-Talk@yahoogroups.com
        Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments


        I wish you would either borrow a Mallincam, of find someone close to you that has one, and go observe with them before defining specifications that will effect all Mallincam users.  We are all different, and each and every one of us use our Mallincams for different purposes.  I know you joined the Mallincam group.  While over there why not ask if anyone lives close to you.  Seeing is be-leaving,   I really wish you could see one or two in action.  I know you are trying to help but I am beginning to think that the Mallincam is so complex, that it might have to have it's own ASCOM driver.  You are really mixing Apples and Oranges, as Rock Mallincam always say.  Have you joined any of the nightskiesnetwork sessions I suggested? This will be my last message on this subject. 

        Tom Hilton
        On 5/20/2012 3:20 AM, Hristo Pavlov wrote:


        Hi Andy,


        I think that this will work but I am not convinced how benefitial it may be. Also in the case where the camera doesn't support any variable exposure - we will need to define what MinVariableExposure and MaxVariableExposure values are going to be. If they are the same value what would that mean. May be we need another property to indicate whether the camera supports variable exposures. Finally I am not sure that "Variable Exposure" is the right name for this. But I don't have a better one.


        Taking a step back, when thinking of defining an interface I always prefer to look from the users' point of view and what they want to do, rather than what the technology permits. Based on this I really don't see why a user will ever want to adjust the exposure of a video camera with a great precision rather than use a fixed set of exposures. Can you give me any reasons why someone may want to do that?



        Hristo Pavlov

        Sydney, Australia


        From: Andy Galasso <andy.galasso@...>
        To: ASCOM-Talk@yahoogroups.com
        Sent: Sunday, May 20, 2012 12:09 PM
        Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments




        Regarding mixing fixed and variable exposure rates, one idea would be to add a pair of attributes like MinVariableExposure and MaxVariableExposure. Then the app could send any of the fixed SupportedExposureRates, or an arbitrary value between MinVariableExposure and MaxVariableExposure. That would cover MallinCams which would provide a set of fixed rates plus a variable exposure range. Other cameras would just provide the set of fixed rates.



        ExchangeDefender Message Security: Check Authenticity
        Complete email hygiene and business continuity solution available from TiGra Networks
        Before replying, please review our email policy

      Your message has been successfully submitted and would be delivered to recipients shortly.