search

jvermillard / leshan

OMA Lightweight M2M java implementation - LWM2M
40 stars 25 forks source link

Add support for observing resources from within web UI #15

Closed sophokles73 closed 10 years ago

sophokles73 commented 10 years ago

I have added initial support for starting observation of resources from within the web UI. So far you can only start to observe, but not cancel an existing observation. However, notifications sent from the client for the observed resources are reflected in the web UI, i.e. the values are dynamically updated :-)

sbernard31 commented 10 years ago

Thx Kai for the pull-request :). I tested it, when I remove the continuation.complete() this works for me, so it's good start. Tomorrow I will create a branch in our repository and we will continue this works.

sbernard31 commented 10 years ago

I tried to separate little changes from the observe feature. Little changes are now committed in master and I created a branch "observe" with the rest of the code. I cleaned some details. We could now continue to work on this branch :). I close this issue.

sbernard31 commented 10 years ago

Kai, I add some modification to the observe feature. You could have a look here, if you want. I remove the observation ID because we don't need it for now.

sophokles73 commented 10 years ago

Hmmm, the LWM2M Spec defines a way to cancel a specific observation. If we want to have an implementation of LWM2M we should therefore provide a way to actually do that, shouldn't we? I can see that "we don't need it right now" would be an argument for not starting implementation of the feature if we did not have it yet. However, I do not see why you would want to remove an existing feature based on that argument. I would like to use leshan in a professional context where LWM2M should serve as a standard contract between devices and our back end. Therefore I think it is important to comply with this contract and thus implement the functionality defined by the spec. Do you think that the Observation ID introduces inappropriate complexity to the API or implementation?

sbernard31 commented 10 years ago

We understand the spec in way that we should offer a way to cancel an observation for a given resource that's why we provide the void cancelObservation(Client client, String resourcepath) method. This seems simple for client use (see APIServlet sample) and make the code lighter. Does it cause a specific problem in your use case ?

We don't see any detail about the implementation in the spec. Could you show us which part of the spec make you think we need observation ID ? We would like to respect the specification as much as possible.

The project is still young and API is far to be stable, the code will probably change often, we want to keep it as simple as possible.

sophokles73 commented 10 years ago

Oh, I failed to notice the cancelObservation(Client, String) method. I thought we would end up with just the possibility to cancel all observations for a particular Client. I don't think that the spec mandates the use of an Observation ID, a client application only needs to be able to uniquely identify, which observation should be cancelled. This works with any of either an observation ID or with a (Client, Resource Path) tuple. I see no problem for our use cases there.