F-1. Enable individual devices to describe their capabilities and available
functions (e.g. frequency range, modulation/waveform types, power levels,
mechanical positioning, etc.) in response to queries from authorized remote
users over IP networks
wsctld completely self configures based on sending the “1” command and parsing its response
F-2. Enable individual devices to report their current state (frequency,
transmit/receive status, etc.) to authorized remote users both spontaneously
and in response to queries;
wsctld can be configured poll rigctld/rotctld by subscribing to certain commands, these will generate events to attached clients
F-3. Enable authorized users to change settings and activate functions of
remote devices over IP networks;
authorisation is designed but not implemented yet
F-4. Respond to authorized users with an indication of the success or
failure of commands, and error messages in response to any failed query;
yep it does.
F-5. Provide low-latency streaming transport for message content
including audio and video and binary objects (e.g., images) both to and from
wsctld does stream audio with a ~250ms delay from radio to browser (implemented last week) and will also be capable of the other way around. It has been optimised for low latency and unbuffered by nature. It works excellent (surprisingly). the audio is send over the same web socket as the command/report protocol by mixing digital and text data. support for video, images etc. should follow.
It will have means of de/-encoding digital modes in the background by plugins.
F-6. Support multiple simultaneous client connections by the same or
different users, and with the same or different access privileges;
Yes it does, even the audio can be streamed to multiple clients at once. there is a locking mechanism for resources and ro/rw support
F-7. Require user authentication using passwords or other equivalent
methods, and provide a mechanism for registering multiple users and their
credentials and access privileges; and,
F-8. Provide simple reference software implementations designed for
cross-platform operation at both the client and server ends.
N-1. Be designed and (for reference implementations) implemented using
cross-platform methods and tools for maximum adaptability and
N-2. Implement network communications using simple text-based
commands and parameters with minimal syntax and formatting in order to
facilitate debugging and user understanding;
it can be packaged for with py2exe or py2app, is multi threaded, uses open standards and protocols (on the edge of current technology)
N-3. Utilize encryption by default on all network links;
wsctld will be updated to implement both the ws and wss protocoll, wss in not implemented yet though. (easy to do)
Follow a modular approach and provide detailed documentation
within the source code to facilitate extensions and specialized interfaces; and,
wsctld is fully objective and can be extended by plug-ins both on server and client and is therefore highly modulair by design, reason for it not being published yet is lack of documentation in the Sources and its relatively early stages of development. I will use something like doxygen.
as it is a one-man show at the moment, I focus on implementing the core functionality and have stable. I have pointed out that a working demo is hosted at http://pb0ner.nl/wsctld.html
as it is connected to the back-end in progress, some functionality will be limited at some time. It is connected to live radio’s/rotors or to the hamlib dummy’s.
have a look at the .html source will get you a brief introduction of what wsctld has to offer on the “ease of use” side.
wsctld.js will however be extended to offer user controls.
N-5. Wherever possible in reference implementations, permit user
configuration of radio interfaces by means of property tables or other easily-