On Tue, Apr 24, 2018, 7:40 PM Heldt-Sheller, Nathan < [email protected]> wrote:
> Ethan if I’m understanding right, you basically want to “do something” in > the Server’s application layer, when the Server receives as discovery > request (multicast to /oic/res). > > > > If that’s right, I think you’ll need to modify the stack… I don’t know of > any way to “hook” the in-stack “entity handler” (the request endpoint) for > /oic/res. Your alternate Resource approach is more in keeping with the > Specification (since side-effects on Discovery aren’t really a thing, > AFAIK), but if that doesn’t work for your use case, then I think you’re > looking at editing IoTivity code. Shouldn’t be too hard really but just > make sure you are careful to not create side effects that change the > Device/Resource state from an OCF perspective… that would be out of line > with RESTful nature of the OCF Reource interfaces… make sense? > Makes perfect sense in the context of the REST model. Unfortunately the REST model makes no sense in the context of interactionist computation. E.g. idempotence is completely meaningless outside of mathematics and/or Turing (functional) computation. The REST model is procrustean. Just think about what GET means. It should return the state of the resource. This will obviously not be idempotent for sensors. Or gowsabout GET /number/of/gets. But there is also no reason it should be idempotent for /oic/res (or any other resource). If the target has added or removed Hue resources since the last GET, then its /oic/res state has changed. I see no reason why the DISCOVERY handler should not mutate the state (side-effect) to reflect current state of the entire system. Put differently: how can a DISCOVERY handler possibly guarantee idempotence? It would have to remember the state as of the previous request. Easy peasy for Turing computation, since that is encoded in the structure of the computation. Impossible for interactionist computing. OCF servers are black boxes, we should not even talk about their state. Same goes for all the other CRUDN methods. E.g. if I get flooded by requests to turn the lights on, then I turn the lights off. Nothing wrong with that, it just doesn't fit the (procrustean) model of RESTful computing. Side-effects are not even possible in Turing/functional computing. They are normal and expected in interactionist computing. What does "side-effect" even mean, from the client perspective? IOW what Ethan wants to do is perfectly ok, no matter how many side-effects are involved. The REST notion that GET should never change the resource is completely incoherent, AFAIK. (I hope that didn't sound overly rantish. Kinda thinking out loud.) Gregg >
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
