Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2m-iwg] TR : [core] CoAP tutorial

Ben/all,

Thanks for the input and trying to clarify the differences or synergies between those protocols.
While he didn't speak to Bertrand from DeviceMap a lot, Mike was also there (and said "bye" to him) when we and a few M2M players like Gemalto/Cinterion discussed the state and outlook for Apache DeviceMap.

Given things like Ponte and a possible need to access device information in different ways, a first step co-committer Reza provided just before our meeting are RESTful Web Services for device information and recognition.

---------- Forwarded message ----------
From: Reza <reza.naghibi@xxxxxxxxx>
Date: Mon, May 13, 2013 at 2:23 AM
Subject: Java webservice
To: Apache Device Map DEV <devicemap-dev@xxxxxxxxxxxxxxxxxxxx>


The Java webservice is available.

Plain HTML:

http://devicemap-vm.apache.org/javaservice.html


JSON:

http://devicemap-vm.apache.org/javaservice.js


JSONP:

http://devicemap-vm.apache.org/javaservice.js?callback=cb1234


All of the above calls can take in a user defined UA parameter:

http://devicemap-vm.apache.org/javaservice.html?ua=Mozilla/5.0%20(iPhone;%20U;%20CPU%20iPhone%20OS%203_0%20like%20Mac%20OS%20X;%20en-us)%20AppleWebKit/528.18%20(KHTML,%20like%20Gecko)%20Version/4.0%20Mobile/7A341%20Safari/528.16


http://devicemap-vm.apache.org/javaservice.js?ua=Mozilla/5.0%20(BlackBerry;%20U;%20BlackBerry%209900;%20en)%20AppleWebKit/534.11+%20(KHTML,%20like%20Gecko)%20Version/7.1.0.346%20Mobile%20Safari/534.11+&callback=abc555


The service is running in the plain DeviceMap Java API in Tomcat7 and being proxied thru nginx. Im using OpenDDR v1.16 data (the DeviceMap svn only has 1.15).


Neither device management nor OMA-DM in particular were found to be of greater interest in our conversation, but some of these efforts may greatly benefit from the device information repository, DeviceMap already has and keeps improving. Check it out, and let us know, if there are aspects you feel could help related efforts here.

Cheers,
Werner

On Mon, May 20, 2013 at 6:00 PM, <m2m-iwg-request@xxxxxxxxxxx> wrote:

Message: 1
Date: Mon, 20 May 2013 14:00:30 +0000
From: Philip Lombardi <plombardi@xxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] TR : [core] CoAP tutorial
Message-ID:
        <6FB37142DB63DE44898632F048736BED0155EF@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Benjamin,

I have been quietly following your M3DA protocol for a bit now, and perhaps I missed it somewhere, but I still do not understand the reason for introducing Yet Another Binary Serialization Format. Why did you not choose one of the well-known existing ones such as Protocol Buffers, ASN.1, MessagePack or BSON. Is there any information out there about the supposed compression superiority of Bysant serialization compared to those binary formats? When you say Bysant is more efficient, what are you referring to exactly? Speed at which it can be encoded and decoded on embedded devices or size of the data after encoding? Introducing a new poorly-understood (and I mean that fully in the context of experience developers have with other more well-known formats and not design) data serialization format for use in the M2M space seems... unnecessary and only makes the barrier to connect devices higher and harder to reach. Not to mention all of those other existing serialization protocols h
 ave a wealth of libraries in existence for serializing, de-serializing and debugging messages encoded in the respective format as well as lots of real-world use and testing.

Cheers,
Phil

-----Original Message-----
From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of Benjamin Cab?
Sent: Monday, May 20, 2013 2:11 AM
To: m2m Industry Working Group
Subject: Re: [m2m-iwg] TR : [core] CoAP tutorial

Mike,

M3DA and LWM2M basically serve similar purposes, in that they can both be used for Device Management _and_ Application data.

LWM2M comes from a Device Management history, and therefore has the
advantage of supporting well all the use cases that OMA-DM supports.
When it comes to Application Data, M3DA has been designed with M2M in mind right from the beginning, and brings a security model with a smaller footprint (CPU and bandwidth) and is more efficient in terms of bandwidth use thanks to the Bysant serialization protocol (LW suggests the use of binary TLV or JSON thus arguably isn't as efficient).
Being based on CoAP, LWM2M allows unicast and multicast, when M3DA only allows 1-to-1 communication between two nodes. This is BTW also one of the main difference between MQTT and M3DA which makes them target different use cases.

Both CoAP and LWM2M look like an interesting addition to the set of protocols we support already at Eclipse M2M, especially with Ponte arriving.
It'd be interesting if one would contribute an open-source implementation of LWM2M, that could possibly be bridged to/from MQTT or M3DA thanks to Ponte? Also, I believe that the experience of our group with MQTT and M3DA is a great opportunity for driving improvements in the CoAP and LWM2M specs.

Others mileage may vary and I'm keen to hear what other think.

Cheers,
Benjamin--






Le 19/05/13 23:18, ? Mike Milinkovich ? <mike.milinkovich@xxxxxxxxxxx> a ?crit :

>Benjamin,
>
>Could you help me understand the differences between the M3DA and OMA
>LWM2M protocols?
>
>Mike Milinkovich
>+1.613.220.3223
>mike.milinkovich@xxxxxxxxxxx

Back to the top