Asynchronous OPeNDAP
A number of solutions have been suggested for how an asynchronous OPeNDAP interaction might be performed.
- Challenge request with some form of "Asynchronous Required" Message (Detailed Discussion)
- Repeat original request till ready (responses: 202, ... 202, 200)
- Original
request includes an "Asynch Allowed" header with max time accepted as
value (e.g., "Asynch-Allowed: 12 * 60 * 60 * 1000 hrs" means willing to
wait 12 hrs)
- Good conversation on asynchronous handling in WCS+
email list. Mostly dealing with options raised in OGC WCS discussions
mainly involving how to indicate the kind of possibly asynchronous
request is desired with "STORE" and "STATUS" parameters. (Summary) Here are the
links to the email list archive:
- Long poll (COMET architecture, LDM) - [[Would this allow multiple requests? No, how know which response getting.]]
There
are two issues: negotiation and notification. Negotiation involves the
client and server deciding if they really want to make the request (if
there is no negotiation, the server may start a long process even
though the client may not want to wait). The notification deals with
how the final results actually get to the client.
Negotiation: 1) none [just do it]; 2) server challenges; 3) client allows.
Notification: 1) none (???); 2) client poll; 3)
