Closed cfra closed 11 years ago
Perhaps #35 might be relevant?
As in a proxy, run by the hackerspace, but not at the hackerspace, to receive requests from clients of the API, and proxy them - to save bandwidth or other reasons?
That's something the spec doesn't cover, I think. Personally what I would do would be to return false, and in the status string send back "proxying error, defaulting to space closed. [alternate method of finding out if the space is open here]" or similar.
If you have a thought on how to handle that better, a suggestion would be welcome.
Anything but returning true/false is of course a deviation from the existing API and prone to break existing applications.
Imho, either one should describe a concise annotation to a "false" state to declare that the state is actually unknown - this complicates the API but keeps it compatible. The other cleaner solution would be to make that field simply optional and omit it when it is not known. Hopefully the applications out there are liberal enough/will adapt so that this incompatible change to the existing API is not a problem.
One way to achieve the tristate is to assign 'null' to the open field. Most (all?) languages evaluate this to false so this meets the 'default false' strategy.
Applications that check for all three values know in what state the space really is.
@joewalnes @trevorpower @fixme-lausanne @grdryn could you please check if allowing null as value for open would break your apps?
"state": {
"icon": {
"open": "http://shackspace.de/sopen.gif",
"closed": "http://shackspace.de/sclosed.gif",
"unknown": "http://shackspace.de/sunknown.gif"
},
"open": null
}
Please consider that the icon URLs are not all working, the json provided by @elf-pavlik is just an example.
Hi, in MyHackerspace, a null value will mark the space as closed, same as if the field is not present.
So to make this clear, here's the policy:
true for open, false for closed and null for undefined.
The documentation is already reflecting this.
I am wondering what a json-providing frontend which queries the hackerspace status should set "open" to, when the hackerspace is unreachable.
I don't see any good solution to this with the current spec. My approach would be to just drop "open" from the status when it cannot be determined, but currently, "open" is mandatory and boolean, so the space always has to be open or closed, there simply is no (machine readable) "unknown".