Subject: Sync Actions vs. Async Actions - do you see a difference?
Not long ago the TRP group adopted a syncReplyMode flag in the message header. The flag allows the requesting party to indicate to the responding party whether or not the response should come as synchronous or asynchronous. The RegRep Services spec editors never had the option of using this flag back during the inception of the action names associated with the ObjectManager and ObjectQueryManager Service Interfaces. However, they do now. In the interests of alignment with TRP I'd like to propose that RegRep dismiss the Async versions of the Actions in these interfaces. The wording and diagramming of the current specification suggests that these Actions are "functions to be called", and that the response documents are "like return types" of those functions. By nature of the syntax used, the payload documents are "like parameters" of those functions. The thin distinction is made between Async and Sync versions of those functions - Async ones do not "return". In practice however, the response documents are the same whether the operation is synchronous or asynchronous, and the payload documents (or parameters) are the same as well. Implementors who had previously written code to support the Async / Sync versions of the actions have a very easy migration path: Rewrite the synchronous Action handler to include logic that will check the syncReplyMode flag of the message. If the flag is false, invoke your existing Async version of your Action handler. If it is true, process as before. This inhibits a faulty client application from setting syncReplyMode to 'true' while at the same time issuing a "GetRootClassificationNodesAsync" message. It also frees a server implementation from having to resolve such inconsistencies. Feedback on this is welcome. -- // Michael Joya // XML Global Research and Development // 1818 Cornwall Ave. Suite 9 // Vancouver, Canada // 604-717-1100x230
eList eXpress LLC