INDI

[AlexRoman]

I'm looking at this from the perspective of an ASCOM developer with virtually no Linux experience.

INDI seemed to specify a communication method without specifying what command must - or should - be implemented and that seemed to leave that to the driver and application to agree about - not sure how.

ASCOM as implement is Windows only because it's COM based but the set of command definitions could be implemented using just about any underlying communication method - I did an experimental network solution where each command and response was parsed into a text string that could send to a server. I made the mistake of implementing it using UDP and the while thing dissolved into a sea of disagreement about the merits of UDP.

I wonder if ASCOM could be used the define the command set and have other ways of implementing the communication between applications and drivers.

Not trying to impose this but wondering if there's something that will help.

Chris

That is true -- there is no "standard" way of implementing a CCD for example. Not defined by the standard at least. But there is a "standard" way if you sub-class the INDI::CCD class. It will define a bunch of these properties for you. Just tonight I've managed to get my QHY9c to take shots with INDI using KStars and the Ekos UI they have. Fairly nice, I have to say. They support having a queue of shots to take, etc. Point being that I've just developed a driver that works with a third party program and I didn't have to do anything too special to adhere to a standard. Let's hope the next version of the standard will incorporate these definitions.

All good points.

* controllers - this follows the natural requirement for low latency and high accuracy for devices. This is really an example of a service.

* ascom - there are aspects I would change, particularly around the management and some rearchitecturing.

What nobody here has mentioned, and the big reason for V2 of AOSX, is saving the work of a frustrated APer - if a driver fails or a component it should have minimal impact.

Please - think of the user... with a simple experience. Otherwise you'll end up being regarded as difficult to use..

The sweet thing about indiserver is that it will respawn the driver if it crashes, for example. It really is up to the driver to behave if it doesn't crash, though. The current QHY9 driver implementation I'm working with (borrowed from a fellow QHY user and modified enough) uses synchronous libusb transfers from within the driver's thread (so during a transfer the driver is unresponsive). Obviously this is bad, but next step is to get asynchronous i/o with callbacks, etc. Shouldn't be a problem to have a driver that behaves correctly in all situations [foreseen by the developer ].

INDI also supports saving a re-loading a driver's configuration and I've got this working mostly out of the box using the standard INDI C++ class methods -- very simple customization. Let's say your driver crashes. No worries, indiserver reloads the driver and the driver loads its previous configuration. The client gets a notification of the device re-appearing so it can easily re-start its current job and/or report an error. This mechanism might be something useful for your AOSX project. By the way -- it would be nice to be able to share some code between Mac and *nix; after all it's all POSIX under the hood...

[simonct]

I like the approach of the local controller. Do you mind sharing the source code somewhere? Sounds like it's along the same lines with what I had in mind...

Sure, here's my current project - sorry for the delay ! It's alll Objective-C so not much use on Linux unless (you're planning on using GNUStep) but some of the patterns might be useful.

Simon

[Daggerstab]

It looks that I'm late to the party...

One thing that everybody should have in mind is the distinction between INDI - the XML-like communication protocol - and indilib/libindi, the INDI library/framework implementation for Linux that comes with a collection of default drivers (and a few "external" ones). INDI-the-protocol has no preference on what it's used, be it TCP/IP, pipes/fifos or something else, and it's not tied to a particular implementation, as the Java thing shows.

I'm working on a Qt-based INDI client for Stellarium, and it's been somewhat unpleasant, partially because INDI is not pure XML and Qt's XML-handling mechanisms have to be coaxed to deal with it. It's also possible that I just suck at programming.

Oh, and if you've noticed the remark on the indilib.org website about a Windows port in its very early stages, that was done by me. And given the time I can spare for it, it won't progress beyond "very early stages" soon.