Create a Shim to interface diffrent implementation of application Layer

[Areontar]

Create a Shim to interface different implementation of application Layer i think is very important,

I would be good to start the discussion around the best way to do this, so i am checking to see who would be interested in working on this with me and who would like to talk the best approach to do this.

I plan on starting the work soon. We can create a wiki page on the subject if people want or i can just go ahead and start implementing.

Thanks

[sbernard31]

1. For communication, maybe we could start without wiki page. Let's try just with issue comments.
   if real time discution is needed, we can use IRC. (#leshan at chat.freenode.net)

2. For coding, you could create a branch in our repo (you have commit right now), if commits comment contains #46, I guess we should see it in the issue timeline.(I know that works with master, I guess it's ok for other branches too)

3. For the approach, we could to this step by step, I think the next logic/behaviour we need to move now from server-cf to server-core is in the RegisterResource. Maybe we could create RegisterRequest, UpdateRequest, DeRegisterRequest (extends LwM2mRequest) with fields described in the spec (§5.2). And a RegisterHandler (we could find a better name :p), which will handle this request and return ClientResponse. The symmetric way, we do to send request from server. I mean currently we have a CoapRequestBuilder and a LwM2mResponseBuilder. We should add a LwM2mRequestBuilder and a CoapResponseBuilder. If it's a good idea, I think client could do the abstraction on the same way.

[sbernard31]

I created a branch shim.
I tried to start an implementation of what I exposed above.
The two main classes are :

• Generic code : RegistrationHandler (this name ... sniff sniff ... 💩 !)
• Californium dependent code : RegisterResource

Finally, there are not so much code which will be reused.

• If we go in this way, we should rename ClientResponse to something like LwM2mResponse.
• I don't know if the ClientUpdate Class is still usefull.
• We lost error message on CoapResponse, if we want to keep them we should add this to ClientResponse/LwM2mResponse.
• I don't implement LwM2mRequestBuilder and a CoapResponseBuilder, I don't know if it's a good idea.

I made that quickly so this is more a way to expose the idea, we could probably improve it.
I guess this kind of idea could be reused at client side, all the interface(maybe even classes) about request/response could be reused at client side.

If I don't answer the two next week. That's not because I'm sulking, I'm just in vacation :p . 🎄

[jschloman]

I like this and the direction it's going quite a bit! I definitely think beginning to merge common objects (such as the Requests) between the server and the client is a good idea. It would also let us make the two halves more uniform in their usage as well (e.g., the client Requests hold the timeout which might be best to push somewhere else).

Right now we too are in the midst of 🎅 and 🎊 so our work will probably have to wait until the New Year. But then we can look at using this branch to implement with another CoAP layer and see if there are any points we would still need to look at refactoring. But until then, enjoy your holiday :)

[jvermillard]

I pushed some code tweaking. I fixed some issues not always related to this branch while
Globally the code is good for me, just two little points:

• when you create a class, please put at least a one phrase class javadoc for expliciting the purpose of the class (it's for @msangoi also )
• I'm not sure about the split of ClientUpdate & UpdateRequest, ClientUpdate is now somewhat anemic

BTW I like the name RegistrationHandler, probably the 🎄 spirit :D

[sbernard31]

I remove the ClientUpdate class (This force me to clean the Client class, there is now immutable)
I renamed ClientResponse in LwM2mResponse.

Finally it's not so bad, I think this is "mergeable".
As you know we will rename some package for the eclipse initial contribution.
This could be a good idea to integrate this in master before.

@Areontar as you worked on this problem before, it could be nice to have some feedback from you ?

For me, the next step to do is to do the same thing with the bootstrap resource but this is probably smarter to finish this before #47.

[sbernard31]

I merge the modification in master. (but feedback is still welcome)

[jschloman]

I like this! We will be using this again to do a CoAP layer swap and if there are any sticking points we'll socialize them up :)

[Areontar]

I have been going through the code and checking the feasibility of a second CoAP impl, so it should give good insight on if we are missing something

On Jan 21, 2015, at 10:33 AM, John [email protected] wrote:

I like this! We will be using this again to do a CoAP layer swap and if there are any sticking points we'll socialize them up :)

—
Reply to this email directly or view it on GitHub #43 (comment).