NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
On Friday 05 October 2007 21:15, Ethan Davis wrote:
For Server capabilities, I came up with 3 or 4 capability types and how
to encode those in terms of both store/allowAsync parameters and just
the store parameter:
1) The server has full store/delay functionality
a) store= {true|false}; allowAsync={true|false}
[NOTE having dropped PUSH, does "store=F, allowAsync=T" make
sense? And how do we handle that?]
b) store={true|false|serverdecide}
Dominic felt "false" and "serverdecide" didn't make sense
together (or was it just those two with out "true"). I think
this combination actually captures the "allowAsync" parameter
very well. "false" doesn't allow async, "serverdecide" does
allow async.
Yes, just to clarify I meant false and serverdecide together didn't make sense. i.e as a server you can't say "I don't support storage" and then say "I'm going to decide whether to or not to store the data".
Still reading the rest of your email... :) Dominic
wcsplus archives: