hello, Mapi notifications can occurs inside any emsmdb_transaction; currently only the notification send by the server inside the emsmdb_transaction_null() in MonitorNotification() are parsed/processed/delivered to the appropriate callback.
To be able to process all the received notifications, the notification structure must comprise the private data to be passed to the notification callback, since in the average mapi call this data is not available. This patch set first [1/2] modify the Subscribe() call and the mapi_notification structure, adding the private_data parameter (also the related Subscribe() calls are update) and add a libmapi call (DispatchNotifications) to force the notification dispatching in a [quite] non blocking way, then [2/2] call ProcessNotification() after each successful emsmdb_transaction() in all the libmapi calls. I split the patch in the hope of making it more managable for review, since it touches a lot of files (with small changes). I think that the main issue is breaking the current API (due to Subscribe() changes), but I think that is necessary in order to reliably process all the mapi notifications. The DispatchNotifications() call allow the caller to implement notification handling both with multi-threading or with polling/select/single thread and also allow easier creation of notification related mapitests, according to the following schema: <initialize notification: Subscribe, ecc.> <do the action that trigger the event to be tested> DispatchNotifications() <test the callback has been invoked with the correct data> Any comments are welcome Paolo
add_private_data.patch
Description: Binary data
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
