Shared 'observe relation' store at CoAP client side. about java-coap

[szysas]

We could start discussing this issue.

I have a proposal such as:

To have a single observation listener for all subscriptions such as:

public interface ObservationListener {
   // return false to will terminate observation 
   boolean onObservation(String resourceUriPath, CoapResponse observation);
}

And observation store interface, that could be implemented as database:

public interface ObservationRelationsStore {
    void add(CoapRequest obsReq);
    String getUriPathOrNull(SeparateResponse obs);
    void remove(SeparateResponse obs);

[sbernard31]

It's hard to me to see how this will be used as I didn't know java-coap so well for now.

But I can try to provide some feedback. (keep in mind that I maybe don't really get what you have in mind)

1. About ObservationListener : not sure resourceUriPath is enough to identify a observation ? I feel that we need the token (maybe it is available in CoapResponse ?) and probably a kind of peer identifier (maybe it is available in CoapResponse transport context ?) OR CoapResponse should be replace by SeparatedResponse` ?

2. About add(CoapRequest obsReq), to store all information I need, I will probably need to attach some userData to CoapRequest? Maybe I will be able to do that using transport context ?

3. About getUriPathOrNull(SeparateResponse obs), remove(SeparateResponse obs), I guess I should be able to find observe relation from identifier based token of Separated Response + peer Identity from SeparatedResponse transport context.

[szysas]

1. About ObservationListener : not sure resourceUriPath is enough to identify a observation ? I feel that we need the token (maybe it is available in CoapResponse ?) and probably a kind of peer identifier (maybe it is available in CoapResponse transport context ?) OR CoapResponse should be replace by SeparatedResponse` ?

Good point, it should be SeparatedResponse

public interface ObservationListener {
   // return false to will terminate observation 
   boolean onObservation(String resourceUriPath, SeparatedResponse observation);
}

2. About add(CoapRequest obsReq), to store all information I need, I will probably need to attach some userData to CoapRequest? Maybe I will be able to do that using transport context ?

Well, that will be called by server when handling new subscription (GET with obs header). What kind of user data are you thinking of? Would it be possible to retrieve such meta data by implementation class of ObservationRelationsStore?

3. About getUriPathOrNull(SeparateResponse obs), remove(SeparateResponse obs), I guess I should be able to find observe relation from identifier based token of Separated Response + peer Identity from SeparatedResponse transport context.

Yes, all those info will be available.

[sbernard31]

Well, that will be called by server when handling new subscription (GET with obs header). What kind of user data are you thinking of? Would it be possible to retrieve such meta data by implementation class of ObservationRelationsStore?

I will probably create a kind of adapter which will implement ObservationRelationsStore interface with an internal reference to Leshan RegistrationStore.

When void add(CoapRequest obsReq); will be called, internally I will call :

https://github.com/eclipse/leshan/blob/33cbe86744774f3a81f215606425a4b3f5d12168/leshan-server-core/src/main/java/org/eclipse/leshan/server/registration/RegistrationStore.java#L100-L109

But I need the registrationId (In LWM2M the observe relation is tied to Registration concept).
When I send the ObserveRequest, I know I send it to the device with the given registration so when the relation is added to the store I must tied it to that registration.

That's why I would like to add the registration id to the coap request when I translate the LWM2M request to CoAP request, so I can find it back on ObservationRelationsStore.add

I hope I'm almost clear 😁

[szysas]

That's why I would like to add the registration id to the coap request when I translate the LWM2M request to CoAP request, so I can find it back on ObservationRelationsStore.add

I hope I'm almost clear

Adding registration-id (or any other meta data) is possible through TransportContext so I don't see issue there.

Yes, that was very clear.

[szysas]

Minor updates to interfaces:

public interface ObservationRelationsStore {
    void add(CoapRequest obsReq);       // contains: Uri-path, Token, IP address, and TransportContext
    void remove(SeparateResponse obs);  // contains: Token, IP address and TransportContext
    Optional<String> resolveUriPath(SeparateResponse obs); // contains: Token, IP address and TransportContext

public interface ObservationListener {
    /**
     * Handles incoming observation
     * @return if false then server will terminate observation by sending RESET
     */
    boolean onObservation(String resourceUriPath, SeparateResponse observation);