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

Re: New Development Effort

Expand Messages
  • Anshul Kanakia
    I am also very interested in knowing what efforts are underway to make ASCOM Platform independent or, at least, cross platform. Having a standard like ASCOM
    Message 1 of 7 , Jan 26, 2011
    View Source
    • 0 Attachment
      I am also very interested in knowing what efforts are underway to make ASCOM Platform independent or, at least, cross platform. Having a standard like ASCOM running in a UNIX based environment would be immensely helpful!

      --- In ASCOM-Talk@yahoogroups.com, "ceterumnet" <draphael@...> wrote:
      >
      > I am underway in developing CCD camera support in PixInsight. One of my goals is to support cameras across Windows, Linux and OS X.
      >
      > I noticed that there was some talk about cross platform ASCOM support eventually...
      >
      > Since I am going to be doing a lot of work towards making these cameras work in a platform neutral way, it would be nice to work in a way that allows the eventual migration towards a platform neutral version of ASCOM - or at least ASCOM on each platform...for example I would like to use the same method names as the interfaces specified in ICamera etc...
      >
      > Is there some additional discussion that is occurring on this topic?
      >
    • Chris Peterson
      I wouldn t expect anything to happen soon. It s a complex problem, and it is only receiving a small amount of attention. If you re a developer, don t wait for
      Message 2 of 7 , Jan 26, 2011
      View Source
      • 0 Attachment
        I wouldn't expect anything to happen soon. It's a complex problem, and it is
        only receiving a small amount of attention. If you're a developer, don't
        wait for a cross-platform ASCOM.

        The best way to be prepared is to develop carefully against the current
        ASCOM standard. That will almost certainly get you 90% of the way to
        whatever cross-platform solution ultimately gets developed. From the
        standpoint of the application, the cross-platform aspect is likely to be
        nearly transparent. Even from the driver viewpoint, most of the methods and
        properties will be identical to the existing ASCOM spec- there will just be
        another layer involved in the communications.

        Chris

        *****************************************
        Chris L Peterson
        Cloudbait Observatory
        http://www.cloudbait.com


        ----- Original Message -----
        From: "Anshul Kanakia" <anshul.p.kanakia@...>
        To: <ASCOM-Talk@yahoogroups.com>
        Sent: Wednesday, January 26, 2011 1:59 PM
        Subject: [ASCOM] Re: New Development Effort


        >I am also very interested in knowing what efforts are underway to make
        >ASCOM Platform independent or, at least, cross platform. Having a standard
        >like ASCOM running in a UNIX based environment would be immensely helpful!
      • ceterumnet
        Great - I am mimicking the ASCOM interface for all of my method names so that a transition will be easy. Thanks, Dave
        Message 3 of 7 , Feb 3, 2011
        View Source
        • 0 Attachment
          Great - I am mimicking the ASCOM interface for all of my method names so that a transition will be easy.

          Thanks,
          Dave

          --- In ASCOM-Talk@yahoogroups.com, "Chris Peterson" <cpeterson@...> wrote:
          >
          > I wouldn't expect anything to happen soon. It's a complex problem, and it is
          > only receiving a small amount of attention. If you're a developer, don't
          > wait for a cross-platform ASCOM.
          >
          > The best way to be prepared is to develop carefully against the current
          > ASCOM standard. That will almost certainly get you 90% of the way to
          > whatever cross-platform solution ultimately gets developed. From the
          > standpoint of the application, the cross-platform aspect is likely to be
          > nearly transparent. Even from the driver viewpoint, most of the methods and
          > properties will be identical to the existing ASCOM spec- there will just be
          > another layer involved in the communications.
          >
          > Chris
          >
          > *****************************************
          > Chris L Peterson
          > Cloudbait Observatory
          > http://www.cloudbait.com
          >
          >
          > ----- Original Message -----
          > From: "Anshul Kanakia" <anshul.p.kanakia@...>
          > To: <ASCOM-Talk@yahoogroups.com>
          > Sent: Wednesday, January 26, 2011 1:59 PM
          > Subject: [ASCOM] Re: New Development Effort
          >
          >
          > >I am also very interested in knowing what efforts are underway to make
          > >ASCOM Platform independent or, at least, cross platform. Having a standard
          > >like ASCOM running in a UNIX based environment would be immensely helpful!
          >
        • dc3dreamer
          ... names so that a transition will be easy. This is a terrific approach! The interfaces themselves, the methods and properties, have proven to be usable and
          Message 4 of 7 , Feb 4, 2011
          View Source
          • 0 Attachment
            > Great - I am mimicking the ASCOM interface for all of my method 
            > names so that a transition will be easy.

            This is a terrific approach! The interfaces themselves, the methods and properties, have proven to be usable and sufficient in the real world. That's a huge part of the total battle. You're standing on the shoulders of giants.

            The most significant feature of ASCOM on Windows is that it is language independent, and thus accessible from virtually all astronomy software regardless of the language it was originally written in. This is possible owing to the language-independent component objects feature of Windows. You can write a class/object in one language and it is callable in the native syntax of  over 20 languages both compiled and script.

            Nothing like this exists on Unix/Linux (including Max OS X). Everyone's "cross platform" solutions have  been something like C-format shareable image libraries (.so, .dll, .whatever) or Java beans or something else that is usable only from one (or at most some) language(s), and thus a subset of astronomy software. There was an effort progressing on ASCOM-Cross, but it was torpedoed by an interminable discussion about network plumbing minutiae and people who insisted it address the needs of cheap embedded controllers directly. The combination shattered the dream and left the work of several sharp people laying by the roadside.

            If your work results in some concrete progress,  please do come back and take up the flag. I would love to see it happen. My battle woulds still hurt but I'll jump back into the crusade if I can help the cause.

              -- Bob

          • ceterumnet
            ... And the view looks great ;-) ... I know :-( ... cross platform solutions have been something like C-format shareable ... I guess there is a back story
            Message 5 of 7 , Feb 5, 2011
            View Source
            • 0 Attachment
              > > Great - I am mimicking the ASCOM interface for all of my method >
              > names so that a transition will be easy.
              > This is a terrific approach! The interfaces themselves, the methods and
              > properties, have proven to be usable and sufficient in the real world.
              > That's a huge part of the total battle. You're standing on the shoulders of giants.
              And the view looks great ;-)

              > The most significant feature of ASCOM on Windows is that it is language
              > independent <http://ascom-standards.org/About/CompatLang.htm> , and thus
              > accessible from virtually all astronomy software regardless of the
              > language it was originally written in. This is possible owing to the
              > language-independent component objects feature of Windows. You can write
              > a class/object in one language and it is callable in the native syntax
              > of over 20 languages <http://ascom-standards.org/About/CompatLang.htm>
              > both compiled and script.
              > Nothing like this exists on Unix/Linux (including Max OS X).
              I know :-(

              > Everyone's
              "cross platform" solutions have been something like C-format shareable
              > image libraries (.so, .dll, .whatever) or Java beans or something else
              > that is usable only from one (or at most some) language(s), and thus a
              > subset of astronomy software. There was an effort progressing on
              > ASCOM-Cross, but it was torpedoed by an interminable discussion about
              > network plumbing minutiae and people who insisted it address the needs
              > of cheap embedded controllers directly.
              I guess there is a back story here?

              > The combination shattered the
              > dream and left the work of several sharp people laying by the roadside.
              > If your work results in some concrete progress, please do come back and
              > take up the flag. I would love to see it happen. My battle woulds still
              > hurt but I'll jump back into the crusade if I can help the cause.
              > -- Bob
              >
              Is there any info on the progress made so far with ASCOM-Cross? Proposals etc...?

              Honestly, there is no way anyone can dream up a UNIX replacement for ASCOM that won't require some 3rd party approach to shared components...granted, that is my opinion. I have been working in the open source community too long to expect the different segments of developers to agree on the right replacement for .NET or even COM.

              Just out of curiosity - did anyone suggest using MONO? I mean, the whole idea behind MONO is .NET - .NET is a standard, and MONO is an implementation of that standard...I hope that this question doesn't ignite some holy war about desktop component models :) I was mainly just curious if there were some threads I should read through to see the kinds of ideas that were laid on the table.

              Thanks!
              Dave
            • dc3dreamer
              I have a fair bit of experience with Mono. It s yet another language and runtime, standing shoulder to shoulder with Java, Python, C++, etc. Mono-Develop is a
              Message 6 of 7 , Feb 5, 2011
              View Source
              • 0 Attachment
                I have a fair bit of experience with Mono. It's yet another language and runtime, standing shoulder to shoulder with Java, Python, C++, etc. Mono-Develop is a reasonably OK IDE, on a par with  Eclipse (well maybe not quite :-)). Personally, I don't like Mono while I really like .NET. Main reason is it is open source with hordes of developers and who knows what sort of quirke, missing details, etc.

                Just to put things into perspective, ASCOM-Cross is not about "cross-platform application development". This seems to be frequently inserted into the discussion, like everyone on Linux is going to dump their language of choice (usually what they learned in university or ???) and (re-)write their astro software in some language that purports to be "write once run anywhere". No one has achieved it. Java and QT come the closest with .NET/Mono a distant third. But forget it. In any case...

                No, ASCOM-Cross is about language-independent, interface-identical, but probably OS dependent drivers for astro devices. The idea is to allow as many languages on a given OS to be used with the drivers.  We realized that the drivers will all have to be written in some (single?) lowest-common-denominator language like C++ or even straight C, then use bindings for the other languages. 

                I could go on, but if you take some time to dig through the incredible noise on ASCOM-Cross, you can find the design docs, block diagrams, and discussions about the high-level architecture that still seems like it would work.

                Just out of curiosity - did anyone suggest using MONO? I mean, the whole idea behind MONO is .NET - .NET is a standard, and MONO is an implementation of that standard...I hope that this question doesn't ignite some holy war about desktop component models :) I was mainly just curious if there were some threads I should read through to see the kinds of ideas that were laid on the table.

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