But feel free to contact us if you have any other question.
Yes, there are other standards and initiatives for astronomy software development. Some of them well established, accepted by the industry, nevertheless Windows only, locked to .Net technologies and without any clear strategy towards IoT and distributed computing. And another with opposite approach. Easy to port to Unix based systems, fully distributed, but not enough standardised in many aspects, quite inefficient for large amount of data and published under license avoiding real commercial use in many situations and thus wider industry acceptance.
That’s why we begun development of INDIGO framework with the goal to take the best from the both worlds – community driven, open to everybody, portable, distributed, efficient, easy to use for developers and invisible for end-users. Why version 2.0 at the very beginning? It can use legacy INDI wire protocol version 1.7 as a fall down option and thus INDIGO protocol version started on 2.0. And unlike in INDI, INDIGO wire protocol version is coupled with the rest of framework.
This is a current list of requirements taken into consideration:
The most important technical difference is the architecture. While in INDI drivers and clients are connected only over a pipe or network connection and each of them is a standalone proces, in INDIGO drivers, agents and clients are connected to a software bus. In the best case (when both drivers and client are the same process) it may speed up the operations 1000x compared to INDI and you still have the possibility to make the bus distributed and to run every piece of the solution in a different process or on a different machine. More efficient architecture means less memory, less CPU usage and thus less energy consumption, if you're running on batteries in the field.
The most important non-technical difference is, that INDIGO is developed from scratch and managed to become a standard. It has a vendor friendly license to encourage not just an open source, but also the commercial development. It has a conservative project management to protect the investment of 3rd party developers to the integration. And unlike INDI it is not tied with a single client application.
The most important difference is, that INDIGO is multiplatform, distributed and asynchronous system by its nature, while ASCOM is Windows/.Net only framework for synchronous control of local devices. ALPACA promises to make it distributed sometime in the future, but it will be still tied with Windows/.Net.
Yes, INDIGO wire protocol adapter has the ability to fall down to legacy INDI wire protocol version 1.7 to maintain backward compatibility with INDI drivers. In this mode also property and item names are mapped to INDI standard corresponding to version 1.2.
If you want use linked driver option or to use different wire protocol, you have to use INDIGO driver.
Yes, if client or application will initiate communication over INDI wire protocol, INDIGO driver will simulate behavior of INDI driver with common base set of properties.
Partially, INDIGO client or application can use INDI Server for Windows as ASCOM-to-INDI bridge out-of-the-box, but probably much more efficient ASCOM driver wrapper for direct linking will come soon.
Currently on Linux and MacOSX both client and server components are supported. On Windows only a client side is implemented.