Stili di filtro e comunicazione delle notifiche

Questa sezione descrive l'interfaccia tra il processo di spooler e i componenti di stampa, ad esempio il processore di stampa, il driver e il monitoraggio.

Filtro delle notifiche

Il tipo enumerato PrintAsyncNotifyUserFilter viene usato per due situazioni. Nel primo di questi componenti di stampa in esecuzione all'interno dello spooler chiama la funzione CreatePrintAsyncNotifyChannel per creare un canale di notifica. Il chiamante passa un enumeratore del tipo enumerato PrintAsyncNotifyUserFilter per specificare quali client in ascolto possono ricevere notifiche. Nella seconda situazione, un client in ascolto chiama la funzione RegisterForPrintAsyncNotifications per la registrazione per la notifica. Il chiamante passa uno degli enumeratori PrintAsyncNotifyUserFilter per indicare le notifiche da ricevere.

typedef enum
{
  kPerUser,
  kAllUsers
} PrintAsyncNotifyUserFilter;

Nella figura seguente l'enumeratore kPerUser viene usato nella chiamata alla funzione CreatePrintAsyncNotifyChannel . Di conseguenza, solo i listener in esecuzione nello stesso account utente dell'utente che ha effettuato la registrazione sono autorizzati a ricevere notifiche.

Nella figura seguente l'enumeratore kAllUsers viene usato nella chiamata alla funzione CreatePrintAsyncNotifyChannel . Di conseguenza, tutti i listener interessati alla stampante o al server possono ricevere notifiche. Si noti che solo gli amministratori possono usare l'impostazione kAllUsers nelle chiamate a questa funzione.

La figura seguente illustra la situazione in cui sia l'utente 1 che l'utente 2 hanno registrato per le notifiche chiamando la funzione RegisterForPrintAsyncNotifications , passando l'enumeratore kPerUser nella chiamata. Delle tre notifiche inviate, l'utente del listener 1 riceve le notifiche dall'utente 1 nella sessione 0 o nella sessione 1. L'utente listener 2 riceve le notifiche dall'utente 2 nella sessione 2.

Se i client in ascolto illustrati nella figura precedente avevano chiamato RegisterForPrintAsyncNotifications, ma questa volta passa l'enumeratore kAllUsers nella chiamata, tutti i listener in tutte le sessioni avrebbero ricevuto le tre notifiche. Si noti che solo gli amministratori possono usare l'enumeratore kAllUsers nelle chiamate a questa funzione.

Administrators

Un amministratore è un utente con diritti di PRINTER_ACCESS_ADMINISTER per l'oggetto di stampa specificato. Un amministratore può inviare notifiche a chiunque e può ricevere notifiche da chiunque. Si noti che il filtro di notifica è ancora applicato.

Nella figura seguente Joe invia una notifica su un canale con kPerUser. Quando il canale viene filtrato in base a questo enumeratore, la notifica deve essere inviata solo alle sessioni che appartengono all'utente 1, vale a dire sessione 1. Tuttavia, la notifica viene inviata anche alla sessione 2, perché è presente un amministratore in ascolto e è in ascolto delle notifiche di questo tipo. Si noti che l'amministratore nella sessione 3 non riceve la notifica, perché i tipi di notifica non sono uguali.

Specifica del tipo di comunicazione

Specificando un tipo di comunicazione, il componente di stampa indica se è prevista una risposta dal client del listener, nonché il modo in cui lo spooler gestisce il caso quando le notifiche vengono inviate da più client.

typedef enum
{
  kBidirectional = 1,
  kUnidirectional,
} PrintAsyncNotifyConversationStyle

Esistono due tipi di comunicazione: unidirezionali e bidirezionali. Nelle comunicazioni unidirezionali, un client in ascolto non risponde a una notifica di spooler. In questo caso, il client in ascolto non può inviare notifiche perché riceve un puntatore all'interfaccia NULL IPrintAsyncNotifyChannel. Nella comunicazione bidirezionale, il client invia una risposta quando riceve una notifica e esegue un dialogo con il componente di stampa. Questo è il caso di notifica dell'interfaccia utente.

La situazione in cui più sessioni ricevono una notifica dell'interfaccia utente merita un commento. In questo caso, lo spooler apre un canale e notifica a tutti i listener che corrispondono ai filtri, inviando loro la prima notifica. Quando il primo listener risponde, lo spooler chiude gli altri canali e il dialogo continua con il primo client.

Se un amministratore , ad esempio, accede prima che un client in ascolto registrato risponda, l'amministratore riceve la stessa notifica dell'interfaccia utente del client in ascolto.

Quando il primo utente ,ad esempio l'amministratore, invia la risposta, lo spooler contrassegna le connessioni con gli altri client come "chiuse". Quando l'altro client in ascolto risponde, riceve un messaggio "canale chiuso".

Tipi di notifica

Il tipo di notifica è un GUID che lo spooler accetta e usa per filtrare i client del listener. Vedere la definizione del tipo PrintAsyncNotificationType nel file di intestazione Prnasnot.h. Qualsiasi client del meccanismo di notifica asincrona spooler può definire il proprio tipo di notifica. Anche se lo spooler non è a conoscenza del significato del tipo di notifica inviato, filtra comunque i client del listener in base al tipo di notifica.

A ogni notifica deve essere associato un tipo di dati di notifica. Questo tipo identifica lo schema dei dati di notifica.

Oltre al tipo di dati di notifica, al canale è associato un tipo, il tipo di canale di notifica. Un mittente di notifica e un client in ascolto usano il tipo di canale di notifica per scopi diversi.

Sul lato mittente del canale, quando un componente di stampa apre un canale, può specificare il tipo di notifiche che intende inviare tramite tale canale. Tutte le notifiche che passano attraverso tale canale devono essere dello stesso tipo del tipo di canale di notifica.

Il mittente deve sempre associare un tipo a una notifica in modo che lo spooler "sappia" come inviarlo ai client in ascolto appropriati. Un client in ascolto deve convalidare i dati in base al proprio schema. Il tipo di notifica identifica questo schema.

Sul lato listener del canale, un client in ascolto può chiedere di ricevere un tipo di notifica specificando un determinato tipo di dati di notifica al momento della registrazione.

Lo spooler definisce un tipo di notifica speciale usato per annunciare ai client in ascolto che il servizio o l'applicazione è morto.

const GUID NOTIFICATION_RELEASE;

Il client in ascolto può ricevere questo tipo di messaggio solo quando viene chiamato il metodo IPrintAsyncNotifyCallback::ChannelClosed .

Handle di registrazione delle notifiche

Quando un client esegue la registrazione per le notifiche, lo spooler lato server gestisce una tabella interna con informazioni sull'applicazione, ad esempio il contesto di sicurezza. L'handle di registrazione delle notifiche è una struttura opaca ricevuta dal client.

Il client può annullare la registrazione per la ricezione delle notifiche solo usando questo handle.