DAP 4.0 Essential Features: Difference between revisions
| Line 41: | Line 41: | ||
|+ Compatibility Matrix | |+ Compatibility Matrix | ||
|- | |- | ||
! Server kind | !scope="col"| Server kind | ||
! 2.0 Client | !scope="col"| 2.0 Client | ||
! Generic client | !scope="col"| Generic client | ||
! 3.x Client | !scope="col"| 3.x Client | ||
|- | |- | ||
!scope="row"| Old Server | !scope="row"| Old Server | ||
| Line 53: | Line 53: | ||
|} | |} | ||
*Server or client Falls back to DAP 2.0 | <nowiki>*Server or client Falls back to DAP 2.0</nowiki> | ||
=== URL Path === | === URL Path === | ||
Revision as of 17:14, 25 January 2011
Short List =
- Version. Encoding/negotiation must use the URL so that client do not need to know about an experimental header (bonus: this will work with protocols other than HTTP).
- Error. We need a way to reliably report errors when they are detected in midstream of data transmission
- NGrid.
- Shared Dimensions
Version
There are three techniques we are looking at and/or have implemented so far:
- Using HTTP MIME headers (which can be generalized to be Request MIME document headers; not limited to HTTP)
- Using a function or keyword in the query string part of the URL
- Making new URLs by adding to the path part of the URL
None are perfect...
HTTP/MIME headers
The existing code uses the XDAP HTTP/MIME header. This could be adapted for use with other protocols but that can be cumbersome. This does not work for clients like web browsers without fairly complex setup. Compounding this is that client libraries are not using it.
Function/keyword
Another idea: Put something in the query part of the URL. This might look like this:
http://test.opendap.org/opendap/data/nc/fnoc1.nc.ascii?dap(3.2),u[0:1:15][0:1:16][0:1:20]
Although parens are not technically allowed in a URL so the result is often the fairly obtuse:
http://test.opendap.org/opendap/data/nc/fnoc1.nc.ascii?dap%283.2%29,u[0:1:15][0:1:16][0:1:20]
Since this would require changing the CE syntax, we could address the parens issue by adding keywords to the set of allowable things passed in a CE. The resulting URL might look like:
http://test.opendap.org/opendap/data/nc/fnoc1.nc.ascii?dap3.2,u[0:1:15][0:1:16][0:1:20]
Both of these URLs have the same basic problem: with a server that does not recognize the function or keyword, the response is an error (a 400 response). So this syntax breaks existing servers, which means that to use this syntax in an automated sense a client needs to check for a 400 response and, if one comes back, guess it might be the function/keyword and try the request without it.
Here's a compatibility matrix:
| Server kind | 2.0 Client | Generic client | 3.x Client |
|---|---|---|---|
| Old Server | Works | Works | Works* |
| New Server | Works* | Works* | Works |
*Server or client Falls back to DAP 2.0
