5. Key Principles and Characteristics

ASCOM establishes a universal connectivity ecosystem for connecting astronomy applications with astronomical devices like mounts, cameras, and focusers (to name a few). Apart from the interface definitions themselves, the ecosystem itself depends on apps and devices adhering to some common principles and characteristics.

These principles are critical to the stability and reliability of observatory systems that use ASCOM universal interfacing.

Devices (and their adapter/drivers) are Stateless
Some devices, particularly cameras and mounts, have modes and conditions. For example, a camera may be set to a certain binning level, or it might be in the process of exposing an image. Also some devices may be used concurrently by more than one app. ASCOM devices are stateless (1). There is no mechanism in ASCOM for managing concurrent but conflicting actions by apps (2). This is by design. Each client app is therefore responsible for getting the device into the needed mode/condition it needs by setting properties and making method calls. Clearly, for example, it makes no sense for a mount to be required to arbitrate multiple student planetarium apps connected to a mount with each of them concurrently trying to move the telescope to a different place, changing its tracking rate, etc.
Device Requests are Asynchronous
In simple terms, this means that apps can ask to start a lengthy operation, during which the device is free to respond to subsequent requests like checking for completion, other status, or even an abort. Legacy ASCOM-COM includes a few synchronous functions/methods that violate this principle. There are always asynchronous versions of these. App developers should avoid using deprecated synchronous methods.
Devices Respond First-Come-First-Serve
When more than one app has concurrent access to a device, the device handles incoming requests in First-In First-Out (FIFO) order. This is by design, and drivers are required to have this behavior.
Do it Right or Signal an Error
A vital principle to all modular systems is Do it right or signal an error. It is illegal (a bug) to accept a function/method call and then do nothing, or worse, do the wrong thing. Likewise, it is a bug to return incorrect data when reading a variable/property, or corrupt a value being written to a property. This may seem obvious but it can be subtle. This has subtle consequences which are covered in the section How Errors are Handled. Don't jump there right now though, the upcoming connectivity sections are vital!
Alpaca is Designed for Local Networks
In order to keep Alpaca as simple and compact as possible, the network protocol is designed to be constrained to within a local network (within an observatory, even including an air-gapped local net). It is not designed for use over the public Internet. The only security provided is username/password. If a system needing encryption or other hardening against a wide-area or public internet environment is needed, users can employ encrypting proxies and other hardened appliances. The point is that the devices themselves can be simple but functional.
No Provision for Network Delays or Limited Bandwidth
A consequence of Alpaca's design for local net only is that Alpaca is purposely kept simple. No provisions for efficiency in the presence of significant network delays or bandwidth limits have been included. When operated in a local environment with network bandwidth being essentially unlimited and delays being essentially zero, and with property reading scattered through app code, little advantage is gained by aggregating property reading(3). The same goes for including the complexity of completion events for asynchronous processes. Communication between apps and devices doesn't include high-frequency processes which operate with the need for millisecond response times, and with essentially zero delay the status of an operation may be determined when needed without significant delay. ASCOM's implementation neutral interfaces don't include provisions for low level real-time servo controls, etc. This is by design. Those type of operations belong inside the device itself.

Now let's look at the real world. First, how this applies to classic ASCOM COM in 6. COM Connectivity.


1Alpaca is ReST which is stateless
2No publish/subscribe or anything like that
3Aggregated properties must be demultiplexed in the app, adding complexity and overhead.