Endpoints

[gabrielschulhof]

We cannot specify an endpoint when calling resource.on( "update" ), just as we cannot specify a query flag. We can only specify those if we initiate observation via client.retrieve( destination, query, listener ). Even there it's pretty awkward because giving a query string for which no observation has yet been initiated results in the creation of a new resource. That is,

client.on( "resourcefound", (resource) => {
  const foundResource = resource;
  function resourceValueChanged( resource ) {
    // Here, resource !== foundResource
  }
  client
    .retrieve( foundResource, { scale: "fahrenheit" }, resourceValueChanged )
    .catch((error) => {console.log(error); process.exit(1);})
});

Perhaps we should rename the ClientResource to ResourceView, because that would make it clear that one can have multiple views of a real resource. Then, each ResourceView would have a fixed endpoint and a fixed query.

@zolkis what do you think?

[zolkis]

Makes sense.

[zolkis]

@nagineni made the point this will conflict with our current way to handle the update event. That used to be a convenient way to observe a resource. Since we cannot pass options (endpoint) to an event listener in general, we need to remove that update event, since we have no way to specify the endpoint when requesting observation.

So the only way to observe a resource will be via retrieve(), i.e. this coap'ism has managed to carve itself into the API...

[gabrielschulhof]

Not if we use ResourceView, because ResourceView has a fixed query string and a fixed endpoint.

…

On Mon, Jan 29, 2018 at 3:51 AM, Zoltan Kis ***@***.***> wrote: @nagineni <https://github.com/nagineni> made the point this will conflict with our current way to handle the update <https://github.com/intel/iot-js-api/blob/master/ocf/client.md#clientresource-events> event. That used to be a convenient way to observe a resource. Since we cannot pass options (endpoint) to an event listener in general, we need to remove that event. So the only way to observe a resource will be via retrieve(), i.e. this coap'ism has managed to carve itself into the API... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7k0ccMQeahkoHhuShRsOauW8DXEawvks5tPYaqgaJpZM4Rt29r> .

[nagineni]

Are we going to have multiple ResourceViews, if a single resource is associated with multiple endpoints?

[gabrielschulhof]

Yes, that's the idea.

…

On Mon, Jan 29, 2018 at 10:09 AM, Sudarsana Nagineni < ***@***.***> wrote: Are we going to have multiple ResourceViews, if a single resource is associated with multiple endpoints? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7k0dbeikYme3geThi9B2ZLsWwbOOurks5tPd8_gaJpZM4Rt29r> .