search

jvermillard / leshan

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

Create a Shim to interface diffrent implementation of application Layer #43

Open Areontar opened 9 years ago

Areontar commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

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

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 . :christmas_tree:

jschloman commented 9 years ago

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 :santa: and :confetti_ball: 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 commented 9 years ago

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:

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

sbernard31 commented 9 years ago

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 commented 9 years ago

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

jschloman commented 9 years ago

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 commented 9 years ago

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 notifications@github.com 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 https://github.com/jvermillard/leshan/issues/43#issuecomment-70870095.