We had a discussion on this week's call where I mentioned this as potentially very general use of Automation artifacts. Here's a brief attempt to put some more meat on the bones.
202 Accepted gets 2 short paragraphs in [2616] and a minor update in the draft RFC long underway to supersede 2616, i.e. "httpbis" where it's hiding in [bispart2]. Where I see this fitting in pretty nicely is anywhere that a given HTTP request might turn out to be long-running (probably only in some cases) and the server wants to allow clients to drop the connection and effectively monitor for asynch completion via a "monitor" resource distinct from the original request's HTTP Request-URI. I say "what if that monitor resource *is* an oslc:AutomationResult?" I think it satisfies the limited text in HTTP/bis without any changes in Automation. The status/verdict fulfills the SHOULD, and Automation was purpose-built to handle the asynch case. The due diligence yet to be done I think is to look for any required AR properties (like the link to an Automation Plan) that are not "obvious" how to fill in... FWIW I think the AP link is trivial; either it's a server-owned URI that's really of no concern to the client (because this all started from an HTTP request), or we find/invent an AP URI that corresponds to each existing HTTP method for which a 202 might surface (or just blanket-cover all of them). 202 is a status code that any HTTP client could observe already; that much is very old news. It's not widely used today, in part because it's often unneeded but also in part because it's underspecified... clients have no solid notion of what a monitor resource is, so there is nothing much to interop on. Saying we use AR as the monitor simply fills in one of the underspecified points that HTTP chose to leave open. [2616] http://tools.ietf.org/html/rfc2616#section-10.2.3 [bispart2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-6.3.3 Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
