>From today's draft agenda: Need to consider recovery/error handling. If bad things happen when creating requests, how does client know if the execution actually occurred
Suggestion: Service providers can only offer synchronous style for plans where multiple identical requests can be created and return the same results - idempotent. I don't know that the asynch style is any better in this regard. The Core discussion point was bad things like lost requests, lost responses, HTTP timeouts. With both synch and asynch, the only way to find the result is using information in the POST-Create for the Request. If anything in that round-trip fails, like the cases above, the semantic result is identical: the client cannot know if the request was actually initiated or not. If the Plan is idempotent then that is useful, insofar as the client can respond by simply repeating the request. If the Plan is not idempotent, the client cannot reliably tell how to respond, regardless of the interaction style in play. (Remember that in the asynch case, the only "handle" the client has to search for its Result(s) is the Request URL - if the create-request round trip fails, it does not receive that URL so it has no input for the query over the Results set). For the particular implementations we have in mind, the requests are idempotent, so adding "requested Plan MUST be idempotent" would not pose a problem for them. It seems awkward to impose that requirement for synch only however if the same logic applies to synch cases, absent some new information. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
