Hi Gregg, Interesting, but yes mostly off-topic ☺ To get back in focus, let me use a simple and concrete example:
Let’s say GET(/a/binaryswitch) returns true or false. By CoAP rules, GET must be “safe”. If GET flips the switch and then sends the new state, that’s breaking the CoAP rules. This is important because if Client calls GET, fail to get an ack (because the response was dropped, say, but Client has no way to know that over UDP), then Client re-sends the GET, and both actually go through causing the state to change twice, I’m getting totally unpredictable results. However, if instead GET does NOT flip the switch, but instead has a different side-effect (let’s say it kicks off an unrelated audit of the attached light’s power consumption or whatever) that’s CoAP-legal. From my reading of his email, I think Ethan’s goal is like the second example and therefore an allowed side-effect of GET. If he can figure out a way to hook the GET call, it should be fine from there. Thanks, Nathan From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Saturday, April 28, 2018 6:50 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com> Cc: Wright, Ethan J <ethan.wri...@charter.com>; iotivity-dev <iotivity-dev@lists.iotivity.org> Subject: Re: [dev] oic/res entity handler On Sat, Apr 28, 2018 at 6:40 PM, Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Hi Gregg, I’m thinking you’re mixing “safe” and “idempotent”. There is some contention about how the term “idempotent” applies to RESTful interfaces, but the CoAP RFC at least clearly defines what is meant (“safe” means essentially no side-effects; “idempotent” means that there isn’t an order-dependency to operations on the RESTful interface… for more thorough description see the CoAP RFC). In CoAP, the GET, DELETE and PUT methods are idempotent; the POST method is not. If you think about that, it’s sensible: you don’t want DELETE(r1), DELETE(r2) to have a different outcome than DELETE(r2), DELETE(r1) because UDP. I guess this is a little off-topic for OCF, but it's interesting (at least to me) so here goes: I am not mixing "safe" and "idempotent". I am challenging the entire paradigm. I think it is fundamentally and irredeemably broken. Mainly because it's trying to apply a computational model (Turing/Lambda) that is entirely inappropriate. Also because, intellectually, it's unbelievably sloppy, From RFC 7252: "CoAP supports the basic methods of GET, POST, PUT, and DELETE, which are easily mapped to HTTP. They have the same properties of safe (only retrieval) and idempotent (you can invoke it multiple times with the same effects) as HTTP (see Section 9.1 of [RFC2616]<https://tools.ietf.org/html/rfc2616#section-9.1>). The GET method is safe; therefore, it MUST NOT take any other action on a resource other than retrieval." RFC 2616: 'In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".' But this is meaningless. What the hell does "retrieval" mean, anyway? Retrieval of what, exactly? But back to the GET method (because the others are a tangent): the GET method must be “safe” (that is, no side-effects) and therefore altering the Resource on GET. That is *not* the same, of course, as saying two GETs must return the same value. Thus your Hue example isn’t really right… the GET method will reflect the current state of the Device, which may change, but NOT as a result of the GET itself. Sorry, I don't think that works. Ethan's use case is precisely one in which a GET may cause a change of state. Look at it this way: Turing (functional) computing involves white (transparent) boxes. Interactionist computing involves black (opaque) boxes. In the latter case, the internal state of a black box is off-limits, therefore we have no business placing constraints on the effects of actions on black-box state. You send a GET (or a PUT, or whatever), and you get a response. That is all. What the receiving black-box does with the GET - other than responding - is none of your business. I'll answer my own question: "retrieval" is meaningless. Actually, it's bullshit: you can take "retrieval" to mean whatever you want it to mean, including changing state before returning the "result" of "retrieval". Your GetNextIterator() example is therefore illegal in CoAP’s definition of RESTful GET… you would need a different interface definition to separate the GET from the POST (increment). Where did GetNextIterator() come from? Not my example. In any case, as I said to begin with: Ethan’s use case is okay, as long as the results of GET to /oic/res aren’t changed by his side-effect functions that are triggered by GET to /oic/res. E.g. kicking off an unrelated operation would be fine; modifying /oic/res would not. Huh? What does "results of GET to /oic/res aren't changed" mean? How can "results" ever change? You send a GET, you get a result. You send another GET, you get another result. There is no change there. Regarding "modifying /oic/res": what does that even mean? It's just a Resource; why should it be immutable? Again, you send a GET, you get a result. What happens on the server side is totally irrelevant from the client perspective - it's a black box, if the server wants to change its internal state in response to a GET, who cares? You get a response, end of story. More importantly: nobody can do anything about it. The OCF protocol can legislate messaging; it cannot (and should not try to) legislate the internal processing of OCF black boxes. It's a protocol, not a computational model. -Gregg
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
