Declarando Slots en Adaptadores D-Bus

Las ranuras de los adaptadores D-Bus se declaran igual que las ranuras públicas normales, pero sus parámetros deben seguir ciertas reglas (para más información, consulte El sistema de tipos Qt D-Bus ). Las ranuras cuyos parámetros no sigan esas reglas o que no sean públicas no serán accesibles a través de D-Bus.

Las ranuras pueden tener un parámetro del tipo const QDBusMessage &, que debe aparecer al final de la lista de parámetros de entrada, antes de cualquier parámetro de salida. Este parámetro, si está presente, se inicializará con una copia del mensaje actual que se está procesando, lo que permite al llamante obtener información sobre el llamante, como su nombre de conexión.

Las ranuras pueden ser de tres tipos

1. Asíncronas
2. Sólo de entrada
3. De entrada y salida

Ranuras asíncronas

Las ranuras asíncronas son aquellas que normalmente no devuelven ninguna respuesta a quien las llama. Por esta razón, no pueden recibir ningún parámetro de salida. En la mayoría de los casos, cuando se ejecuta la primera línea de la ranura, la función que llama ya ha reanudado su trabajo.

Sin embargo, las ranuras no deben depender de este comportamiento. Los problemas de programación y envío de mensajes pueden cambiar el orden en el que se ejecuta la ranura. El código que pretenda sincronizarse con el llamador debe proporcionar su propio método de sincronización.

Las ranuras asíncronas se marcan con la palabra clave Q_NOREPLY en la firma del método, antes del tipo de retorno void y el nombre de la ranura. La ranura quit() en el ejemplo D-Bus Complex Ping Pong es un ejemplo de esto.

Ranuras de sólo entrada

Las ranuras de sólo entrada son ranuras normales que toman parámetros pasados por valor o por referencia constante. Sin embargo, a diferencia de las ranuras asíncronas, el llamador usualmente espera la finalización del llamador antes de reanudar la operación. Por lo tanto, las ranuras no asíncronas no deben bloquearse o deben indicar explícitamente en su documentación que se bloquearán.

Las ranuras de sólo entrada no tienen ninguna marca especial en su firma, excepto que sólo toman parámetros pasados por valor o por referencia constante. Opcionalmente, las ranuras pueden tomar un parámetro QDBusMessage como último parámetro, que puede utilizarse para realizar un análisis adicional del mensaje de llamada al método.

Ranuras de entrada y salida

Al igual que las ranuras de sólo entrada, las ranuras de entrada y salida son aquellas en las que la persona que llama espera una respuesta. Sin embargo, a diferencia de las de sólo entrada, esta respuesta contendrá datos. Las ranuras que envían datos pueden contener referencias no constantes y también pueden devolver un valor. Sin embargo, los parámetros de salida deben aparecer todos al final de la lista de argumentos y no pueden tener argumentos de entrada intercalados. Opcionalmente, puede aparecer un argumento QDBusMessage entre los argumentos de entrada y los de salida.

Respuestas automáticas

Las respuestas a los métodos son generadas automáticamente con el contenido de los parámetros de salida (si los hubiera) por la implementación de Qt D-Bus. Las ranuras no necesitan preocuparse de construir objetos QDBusMessage adecuados y enviarlos a través de la conexión.

Sin embargo, la posibilidad de hacerlo sigue ahí. Si la ranura descubre que necesita enviar una respuesta especial o incluso un error, puede hacerlo utilizando QDBusMessage::createReply() o QDBusMessage::createErrorReply() en el parámetro QDBusMessage y enviarlo con QDBusConnection::send(). La implementación de Qt D-Bus no generará ninguna respuesta si la ranura lo hiciera.

Respuestas retardadas

En algunas circunstancias, es posible que la ranura a la que se llama no pueda procesar la solicitud inmediatamente. Esto ocurre con frecuencia cuando la solicitud implica una operación de E/S o de red que puede bloquearse.

Si este es el caso, la ranura debe devolver el control al bucle principal de la aplicación para evitar la congelación de la interfaz de usuario, y reanudar el proceso más tarde. Para ello, debe hacer uso del parámetro extra QDBusMessage al final de la lista de parámetros de entrada y solicitar una respuesta retardada.

Hacemos esto escribiendo una ranura que almacena los datos de la petición en una estructura persistente, indicando al llamador mediante QDBusMessage::setDelayedReply(true) que la respuesta se enviará más tarde.

struct RequestData
{
    QString request;
    QString processedData;
    QDBusMessage reply;
};

QString processRequest(const QString &request, const QDBusMessage &message)
{
    RequestData *data = new RequestData;
    data->request = request;
    message.setDelayedReply(true);
    data->reply = message.createReply();

    appendRequest(data);
    return QString();
}

En este caso, el valor de retorno no es importante; devolvemos un valor arbitrario para satisfacer al compilador.

Cuando la petición es procesada y una respuesta está disponible, ésta debe ser enviada usando el objeto QDBusMessage que fue obtenido. En nuestro ejemplo, el código de respuesta podría ser algo como lo siguiente:

void sendReply(RequestData *data)
{
    // data->processedData has been initialized with the request's reply
    QDBusMessage &reply = data->reply;

    // send the reply over D-Bus:
    reply << data->processedData;
    QDBusConnection::sessionBus().send(reply);

    // dispose of the transaction data
    delete data;
}

Como se puede ver en el ejemplo, cuando existe una respuesta retardada, el valor o valores de retorno de la ranura serán ignorados por Qt D-Bus. Sólo se utilizan para determinar la firma de la ranura cuando se comunica la descripción del adaptador a aplicaciones remotas, o en caso de que el código de la ranura decida no utilizar una respuesta retardada.

La respuesta retardada se solicita a Qt D-Bus llamando a QDBusMessage::reply() sobre el mensaje original. A partir de ese momento, es responsabilidad del código llamado enviar una respuesta al emisor.