|
a/doc/libupnpp-ctl.txt |
|
b/doc/libupnpp-ctl.txt |
|
... |
|
... |
| 117 |
(some of which also work with video). You will usually not need to bother
|
117 |
(some of which also work with video). You will usually not need to bother
|
| 118 |
constructing the service interface objects: rather you will let the device
|
118 |
constructing the service interface objects: rather you will let the device
|
| 119 |
classes do it and return a handle (but there is nothing to prevent you from
|
119 |
classes do it and return a handle (but there is nothing to prevent you from
|
| 120 |
building the service objects directly).
|
120 |
building the service objects directly).
|
| 121 |
|
121 |
|
| 122 |
The library also has helper functions for helping with the independant
|
122 |
There are two possible approaches for accessing a service which does not
|
| 123 |
implementation of a service interface, obtained by deriving the base
|
123 |
have a predefined interface class in the library:
|
|
|
124 |
|
|
|
125 |
- Use the library helper functions for implementing a specific service
|
|
|
126 |
interface, by deriving from the base
|
| 124 |
link:refdoc/html/classUPnPClient_1_1Service.html[Service class].
|
127 |
link:refdoc/html/classUPnPClient_1_1Service.html[Service] class.
|
|
|
128 |
- Use the xref:TypedService[TypedService] generic string-based interface
|
|
|
129 |
class.
|
|
|
130 |
|
| 125 |
|
131 |
|
| 126 |
== Predefined Service classes
|
132 |
== Predefined Service classes
|
| 127 |
|
133 |
|
| 128 |
* link:refdoc/html/classUPnPClient_1_1RenderingControl.html[UPnP AV
|
134 |
* link:refdoc/html/classUPnPClient_1_1RenderingControl.html[UPnP AV
|
| 129 |
Rendering Control]
|
135 |
Rendering Control]
|
|
... |
|
... |
| 139 |
* link:refdoc/html/classUPnPClient_1_1OHSender.html[Open Home Songcast Sender]
|
145 |
* link:refdoc/html/classUPnPClient_1_1OHSender.html[Open Home Songcast Sender]
|
| 140 |
|
146 |
|
| 141 |
The role of most methods in these classes is to marshal the input data into
|
147 |
The role of most methods in these classes is to marshal the input data into
|
| 142 |
SOAP format, perform the SOAP call, then marshal and return the output
|
148 |
SOAP format, perform the SOAP call, then marshal and return the output
|
| 143 |
data. They are all synchronous.
|
149 |
data. They are all synchronous.
|
|
|
150 |
|
|
|
151 |
[[TypedService]]
|
|
|
152 |
== String based interface
|
|
|
153 |
|
|
|
154 |
The link:refdoc/html/classUPnPClient_1_1TypedService.html[TypedService]
|
|
|
155 |
class provides access to the actions in a service through a simple
|
|
|
156 |
string-based interface.
|
|
|
157 |
|
|
|
158 |
The user only needs specify an action name and a list of arguments to call
|
|
|
159 |
an action. The class uses the service description retrieved from the
|
|
|
160 |
device to generate the actual SOAP call. Any returned data is provided
|
|
|
161 |
through a C++ name-value map.
|
|
|
162 |
|
|
|
163 |
The class also has an associated
|
|
|
164 |
link:refdoc/html/namespaceUPnPClient.html#ad3edfb36acb86cb98961233b127fc3df[helper
|
|
|
165 |
function] which provides a simplified interface to discovery.
|
|
|
166 |
|
|
|
167 |
While the class is less convenient to use than one customized to a single
|
|
|
168 |
service, which can provide full encoding/decoding between SOAP data and a
|
|
|
169 |
natural C++ interface, it avoids having to write the corresponding code. It
|
|
|
170 |
was mostly implemented as a convenient interface for the SWIG module, but
|
|
|
171 |
it can probably have other uses.
|
|
|
172 |
|
| 144 |
|
173 |
|
| 145 |
== Eventing
|
174 |
== Eventing
|
| 146 |
|
175 |
|
| 147 |
UPnP services can report changes in their state to Control Points through
|
176 |
UPnP services can report changes in their state to Control Points through
|
| 148 |
events. In practise, the Control Point implements an internal HTTP server
|
177 |
events. In practise, the Control Point implements an internal HTTP server
|