cumbia-http 1.x
Qt widgets on top of the cumbia C++ library
Public Member Functions | List of all members
CuHttpControlsReader Class Reference

#include <cuhttpcontrolsreader.h>

Inheritance diagram for CuHttpControlsReader:
Inheritance graph
[legend]

Public Member Functions

 CuHttpControlsReader (Cumbia *cumbia, CuDataListener *tl)
 
virtual ~CuHttpControlsReader ()
 
void setSource (const QString &s)
 Enqueue a request for either a single shot reading and an optional subscription for data updates through the channel. More...
 
QString source () const
 
void unsetSource ()
 unlink the listener and, if the source is "subscribed", send an "unsubscribe" request More...
 
void setOptions (const CuData &o)
 
CuData getOptions () const
 
virtual void sendData (const CuData &d)
 Send data to the service managing this reader. More...
 
virtual void getData (CuData &d_ino) const
 

Constructor & Destructor Documentation

◆ CuHttpControlsReader()

CuHttpControlsReader::CuHttpControlsReader ( Cumbia *  cumbia,
CuDataListener *  tl 
)

◆ ~CuHttpControlsReader()

CuHttpControlsReader::~CuHttpControlsReader ( )
virtual

Member Function Documentation

◆ getData()

void CuHttpControlsReader::getData ( CuData &  d_ino) const
virtual

◆ getOptions()

CuData CuHttpControlsReader::getOptions ( ) const

◆ sendData()

void CuHttpControlsReader::sendData ( const CuData &  data)
virtual

Send data to the service managing this reader.

Parameters
datathe data to send

\list keys

  • read a read command
  • args a list of arguments to change on the source. This is valid for readings with input arguments only (e.g. Tango commands with argins)
note
Potentially, the http service shares sources across different clients. Changing the arguments (through the args key) of a shared source may lead to unwanted results for the other clients reading the same data. In this case, an edit command is issued. Issuing a read has only the side effect of potentially refreshing all clients connected to the same source.

On the other hand, if the "manual" option is enabled for the current reader, then a new read is requested through http, which should be quite safe.

References CuHTTPActionEditFactory::setOptions(), and setSource().

◆ setOptions()

void CuHttpControlsReader::setOptions ( const CuData &  o)

◆ setSource()

void CuHttpControlsReader::setSource ( const QString &  s)

Enqueue a request for either a single shot reading and an optional subscription for data updates through the channel.

Parameters
sthe name of the source

The reader always performs a synchronous immediate reading.

CuHttpControlsReader stores a method property that determines the behaviour of the reader and can either be:

  • read, only one reading is performed "synchronously", that is, an http reply is sent in response to the request;
  • s, subscribe mode: the single shot reading (as above) is followed by updates through the channel

The single shot only read mode is activated by either single-shot or manual option set on the CuHTTPReaderFactory.

Moreover, if the options contain the property key set to true, the synchronous reply shall contain the source configuration alongside its value. Otherwise, only the value will be fetched.

References CuHTTPActionReaderFactory::mergeOptions(), and CuHTTPSrc::prepare().

Referenced by sendData().

◆ source()

QString CuHttpControlsReader::source ( ) const

◆ unsetSource()

void CuHttpControlsReader::unsetSource ( )

unlink the listener and, if the source is "subscribed", send an "unsubscribe" request

unsetSource will send an unsubscribe request if the method for this source is "s" (the source is monitored on a channel).

Important note
If you are deleting the reader explicitly from the application, call unsetSource and then delete the reader. Deleting the reader without calling unsetSource first will not send an unsubscribe request to the client.

On the other hand, the class destructor alone will not send an unsubscribe request, to avoid flooding the server with unsubscribe requests at application shutdown. In this case, a global unsubscribe request is sent by CumbiaHttp for the entire client application

The implementation somehow differs from the other cumbia engines (for example cumbia-tango, where the destructor actually performs a thorough disconnection from the Tango device) but ensures a consistent and simple unsetSource interface across the engines.


The documentation for this class was generated from the following files: