Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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: