I have been reading about Ascom Alpaca and would be interested to hear views of others.
If this new distributed Ascom works especially the initial "Remote Ascom" ( the ability to split Ascom applications and Hardware devices across numerous devices - initially Windows) then I would have thought Ascom is taking the "lead" over other Astro Computing in that the existing tried and tested Windows applications can now run on a laptop while Mount ,Focuser , camera's(?) etc on "Mini Windows PC" mounted on the Telescope or pier. Sounds a lot like Indi doesn't it !!!!!!
The biggest advantage it has , IMHO, is that 2 parts (application and drivers) of the 3 part system are already in existence and have been heavily tried and tested. The 3 part the "Remote Interface" - the bit that acts as the transparent gateway that allows the Applications to reside on another PC to talk to the Hardware on another PC - is the new and untried item . BUT having ried and tested Applications and hardware drivers is / could be a very big advantage.
The longer term Alpaca Ascom claims to give the ability to run on any OS (heard that before somewhere) but of course does not exist - YET! And needs vendor participation to succeed IMO
Of course anything new will not show up problems until it starts to be used in earnest - so time will tell.
I recently added native Alpaca support to Cartes du Ciel and CCDciel. So you can now use devices connected to a remote Windows computer from the application running on Linux or Mac, and use a mix of INDI and Alpaca devices if you want.
This is interesting for a multi-platform application because this extend what we are accustomed to do with INDI, by using the devices connected on Linux or Mac from any other platform.
Sure at some point this is can be a "concurrent" for INDI but I prefer to see the complementary this protocol offer.
And if the equipment manufacturer start to offer a native Alpaca support for their devices this will be much better for us than the old Windows technology they actually use.
What was the network traffic like and did this cause your applications any issues - REST /HTTP is a "very chatty protocol" ?
In my view it fills a whole where Indi isn't really suppoted - Windows (and Win 32 - yes many still use Win32 esp on tablets) plus having access to fully tested applications (e.g. CDC etc) and tested Windows Ascom drivers is a bonus.
IF (BIG IF) OEM do support Alpaca especially on Linux / Mac (natively) then its got to be a plus IMO
At the protocol level there is a small overhead for the http headers but the json message itself is light.
The network traffic depend on the application poling rate because this still work as ASCOM, i.e. the application query the driver to know if something change.
This give more traffic than INDI where this is the driver that send the new data if something change in the device.
Sure you not need to query your focuser ten time per second all the night to know if it as moved by itself. But with Alpaca it is the application responsibility to make a reasonable use of the resources.
As with INDI the biggest load is when you download an image from the camera.
With Alpaca this return a json array and sure this require some processing on both side to convert from and to binary.
This is quite interesting especially if fully opened source. I've been playing around with the idea of providing a REST interface for INDI as well, but it's going to a lot of effort to make this layer.
I beleive the ASCOM developers finally realized the limitations of their legacy implementation and made good steps with the architecture now. It has yet to be seen how this plays out in the real world.
Interestingly I have been playing with MQTT/JSON to attach multiple DSLR camera's using GPHOTO - wouldnt take much (maybe) to change this to interface with Ascom Remote/Alpaca as it uses Json as do I. I was surprised (nice surprise) that Blobs went across local networks as fast as Indi . For me the beauty of MQTT is you dont need to know anything of the whereabouts of the remote devices (IP address's etc).
Having done some more reading and lightening to he Youtube vid's it appears it is ALL Open Source (I am a scenic by nature ) and they even show a Linux Rotator (in simulation mode LOL ) with Skyx on Windows and the python code on PI - very interesting.
As you say Jasem they have finally learned Ascom limitations - no more COM/USB (ok well maybe not quite)
It is a bit biased in that its all Visual Studio 2017 ( which you guy probably love - i hate it) - even for editing Python on Windows and GIT it to PI but that is the root of Ascom - Windows.
Interesting times indeed. With INDI, maybe it wouldn't be a lot of work if we have an XML <---> JSON conversion layer. With this, we can add REST API support in no time since we can simply convert the JSON calls to XML which are then passed right away to the drivers.
At the moment mine isn't for Indi just to use Gphoto2 connected camera from anywhere bu the principle is the same.
IBM wrote a good paper on using MQTT for "serious" Astronomy to share/control data/devices over the world. Biggest plus as I see it is not having to know where the device are. IBM had developed an Ascom wrapper for MQTT but now with Alpaca/Indi maybe it will provide best of all flavours.
Jasem, maybe you should look at INDIGO XML vs. JSON HTTP/WebSocket mapping before you will try to reinvent the wheel. Among INDIGO web applications it is used also by INDIGO ASCOM drivers for years. Peter