In the absence of the QMF object updates available to Cumin for slot and submission updates, Aviary will attempt to provide an alternative mechanism for these notifications.

A client such as Cumin will register a callback endpoint to Aviary by which the appropriate Aviary endpoint will push one-way updates for slot (e.g., state, activity) and submission (e.g., running, idle totals) changes. This callback interface will be expressed externally to the client in WSDL by which they can provide a generic URI that Aviary will use to push a payload (XML to start) of updates to the receiver. The one-way operation will be InOnly and only synchronize to the HTTP/HTTPS transport, not the remote implementation. Thus, the receiver will have to consume the message and process it in a different thread to maintain system throughput.

The client will also be able to specify a batch size and frequency upon registration which will be used by Aviary to implement a per-client throttle policy. These may be governed by hard and soft limits specified within Condor/Aviary configuration. Graceful disconnects will be the repsonsibility of the registering client through a provided WSDL operation (e.g., "unregister"). However, garbage collection of dangling registrants will also be implemented based on a TBD policy.