Classes | Typedefs | Enumerations | Functions

# Common
[HUPnP Core]

## Classes
class | HActionInfo
| This class is used to contain information of a UPnP action found in a UPnP service description document. More...
class | HDeviceInfo
| This class is used to contain information of a UPnP device found in a UPnP device description document. More...
class | HDiscoveryType
| A class that depicts the different discovery types used in UPnP networking. More...
class | HProductToken
| This class represents a product token as defined in the RFC 2616, section 3.8. More...
class | HProductTokens
| This class is used to parse the product tokens defined by HTTP/1.1. More...
class | HResourceType
| A class used to depict a UPnP resource, which is either a UPnP device or a UPnP service. More...
class | HServiceId
| Class that represents the service identifier of a UPnP service. More...
class | HServiceInfo
| This class is used to contain information of a UPnP service found in a UPnP device description document. More...
class | HStateVariableInfo
| This class is used to contain information of a UPnP state variable found in a UPnP service description document. More...
class | HUdn
| A class used to depict a Unique Device Name (UDN), which is a unique device identifier that has to remain the same over time for a specific device instance. More...
class | HClonable
| This class defines an interface for cloning instances of polymorphic classes. More...
## Typedefs
typedef QList< HEndpoint > | HEndpoints
## Enumerations
enum | HInclusionRequirement { InclusionRequirementUnknown = 0, InclusionMandatory }
## Functions
void | SetLoggingLevel (HLogLevel level)
void | EnableNonStdBehaviourWarnings (bool arg)

## Typedef Documentation

typedef QList<HEndpoint> HEndpoints

This is a type definition for a collection of Herqq::Upnp::HEndpoint instances.

See also:
  HEndpoint

## Enumeration Type Documentation

enum HValidityCheckLevel

This enumeration is used to specify the strictness of argument validation.

Enumerator:

  StrictChecks | The arguments are validated strictly according to the UDA v1.0 and v1.1 specifications.
  LooseChecks | The validation allows slight deviations from the UDA specifications in an attempt to improve interoperability. The accepted exceptions have been encountered in other UPnP software that are popular enough to warrant the exceptional behavior.

enum HInclusionRequirement

This enumeration specifies whether a component of the Device Model is mandatory within a specific UPnP device.

In more detail, any component of the device model (a device, a service, a state variable or an action) may be specified as a mandatory or an optional part of a UPnP device; for example, a UPnP device may have two mandatory embedded devices and one optional embedded device. The same applies to the other components as well.

When HUPnP builds an object model of a UPnP device, this information can be used in validating a description document, or verifying that the provided implementation (HDevice, HDeviceProxy, HService and HServiceProxy derivatives) accurately depicts a description document.

For instance, if the author of a subclass of a server-side HService has specified that a particular action is mandatory, the user of the class, who is the one that provides the description document, has to make sure that the description document also contains the definition of the action.

These types of mappings are optional, but they are highly useful in case the component is to be used as a public part of a library. They help to ensure that the implementation back-end reflects the used description documents appropriately. This is important, as it is the description documents that are transferred from servers to clients and it is these documents that advertise what a particular UPnP device supports and is capable of doing.

From the client's perspective they are also useful in defining requirements for a particular device type. For instance, if you are an author of a HDeviceProxy or HServiceProxy derivative class and you have written the component to work using a specific configuration that requires the presence of certain actions and state variables on the server side, HUPnP can use these requirements to filter devices that are suitable in terms of advertised capabilities.

Enumerator:

  InclusionRequirementUnknown | This value indicates that the inclusion requirement for the component is not specified. This value is used only in error situations.
  InclusionMandatory | This value indicates that the component has to be appropriately specified. It is a critical error if the component is missing.
  InclusionOptional | This value indicates that the component is optional and may or may not be specified.

enum HLogLevel

This enumeration specifies the logging levels that can be used with the device host.

Enumerator:

  None | No logs are generated. Remarks: by default, HUPnP uses this logging level.
  Fatal | Only fatal messages are logged. Most often a fatal message is followed by termination of the application.
  Critical | Only critical and fatal messages are logged. Most often a critical message signals a severe runtime error.
  Warning | Messages with level set to warning, critical and fatal are logged. A warning message usually signifies an error or exceptional situation that should be noted. Most often the system stability is not at stake when warning messages appear, but they may still indicate that some component, internal or external, is not functioning correctly. Usually the source of warnings should be investigated.
  Information | All but debug level messages are logged. An informational message is used to log status information of control flow. A good example of an informational message is when a sizable component logs the start of an initialization procedure.
  Debug | All up to the debug messages are output. This excludes only the function enter and exit messages. Remarks: Enabling this level of logging has notable effect on performance. This generally should be used only for debugging purposes.
  All | Every log message is output. This includes even the function enters and exits. Remarks: Enabling this level of logging has severe effect on performance. This is very rarely needed and usually the debug level is far more helpful.

## Function Documentation

void H_UPNP_CORE_EXPORT SetLoggingLevel | ( | HLogLevel | level | ) |

Sets the logging level the HUPnP should use.

Parameters:

  | level | specifies the desired logging level.

Remarks:
  - The new logging level will take effect immediately.
  - The function is thread-safe.

void H_UPNP_CORE_EXPORT EnableNonStdBehaviourWarnings | ( | bool | arg | ) |

Enables / disables warnings that relate to non-standard behavior discovered in other UPnP software.

Most often if non-standard behavior in other UPnP software is discovered, it isn't fatal or critical and it may be possible to inter-operate with the software. However, deviations from the specifications and standards are unfortunate and such errors should be fixed.

Regardless, you may not want to be notified about these warnings in which case you can specifically disable all the warnings that relate to non-standard behavior.

Parameters:

  | arg | specifies whether to output warnings that are about non-standard behavior in other UPnP software.

Remarks:
  by default, the non standard behavior warnings are on.