On 06/20/2016 01:28 PM, Gregg Reynolds wrote: > > On Jun 20, 2016 2:00 PM, "Gregg Reynolds" <dev at mobileink.com <mailto:dev > at mobileink.com>> wrote: >> >> hello iotivitians. iotivitors? iotiviots? >> >> My latest post to the Intel Ultimate Coder for IoT competition just went >> live at >> https://ultimatecoder.intel.com/iotivity-app-structure-think-servlets/ . >> It's a little rash, since it's based on what I (think i) understand rather >> than experience. I would appreciate feedback (esp. on the blogsite). The >> basic idea is that comparing Iotivity processing to Java Servlet processing >> makes it a little easier to grok the Iotivity model. >> > Something that occurred to me after I posted : in Iotivity, "resources" is a > misnomer. The resource will generally be a physical device or instrument (or > property, etc). In the Iotivity stack, what is called a "resource" is > better thought of as a kind of interaction manager. It manages the > interactions between clients and instruments (widgets, devices, whatever). > Just like a Java servlet functions as an intermediary between a client and, > say, a customer record in a database. If you think of modelling instruments > as distinct from defining iotivity "resources" this makes sense - the > resource (which is running code) services requests by *using* a model of the > instrument, e.g. mraa.
I guess you could express it that way, but the term resource has always be intended to be used in the sense of the World Wide Web, which starts from a very simple explanation of resource: item of interest. A resource always has a URI, which lets you talk to the server hosting the resource using RESTful interactions that can pass around representations of the resource. I find that a comfortable/familiar idiom and don't think of it as a misnomer :)
