That is very good feedback. As in most cases, we are in a context where bandwidth matters, the approach would be to have a ‘discovery’ or separate metadata synchronization model rather than including this information in each data transmission. To that extend, M3DA already provides a shortcut mechanism (originally in order to improve bandwidth) which is out of band synchronized. It could be very valuable to add units and other optional metadata to that synchronization process. Cuero De : m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] De la part de Rick Bullotta
Envoyé : vendredi 1 février 2013 14:38
À : m2m Industry Working Group
Objet : Re: [m2m-iwg] M3DA protocol proposed as part of initial contribution of Mihini (Fabien Fleutot) Hi, all. This is a key reason why rich metadata is *ESSENTIAL* for a modern M2M application. Metadata needs to be discoverable separate from data transmission as well. A consumer of data should be able to “learn” about the data before actually receiving it. Regarding transmission of metadata with the data, that’s somewhat of an application-specific decision. At a bare minimum, data type needs to be part of the data packet (to enable streaming and compression more easily), but there are many benefits to transmitting richer metadata also (particularly for loosely coupled clients). Perhaps making it an optional element negotiated at subscription time would be ideal. Rick Fabien/all, Thanks a lot for the input. Neither UOMo nor OpenXC should require you to have a PhD or other Academic degree, though the latter is so far restricted to SI alone like OSGi Measurement once did, and that alone IMHO caused it to be very little adopted. Looking at the M3DA proposal, using types like those "Number" instances instead of a true Quantity/Unit type looks highly dangerous. Most of us know, that NASA Mars Explorer avoided a proper Unit context in its payload, and even between different subsystems of the same vehicle, this caused its loss and of the 125 Mio. US$ behind it;-/ If you speak of device <--> backend in an M2M context, what would that be, another device or vehicle, or just a stationary entity, think of "toll both" talking to a car, since cars were already used as example. The Automotive IWG might know that even better, but I assume most in this IWG equally understand, that such "backend" would rapidly change for a moving device. On one hand you'll have failover and redundancy, so if the backend was to know about Units of Measurements behind all these context-less sets of numeric data floating between device and backend, then some form of "session replication" and "persistence" is inevitable, otherwise the data makes no sense any more, even to the "dumb" device which has no unit knowledge of its own. If devices move between backends, imagine a car going from Canada to the US. I guess most Canadians here know what the "Gimli Glider" was, and without ALL backends in a large multi-national distributed system being on the same unit system, this may easily happen to a car on such trip if it exchanges fuel level or just its vehicle speed with those ground units. On Thu, Jan 31, 2013 at 6:00 PM, <m2m-iwg-request@xxxxxxxxxxx> wrote: Send m2m-iwg mailing list submissions to
m2m-iwg@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
or, via email, send a message with subject or body 'help' to
m2m-iwg-request@xxxxxxxxxxx
You can reach the person managing the list at
m2m-iwg-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of m2m-iwg digest..."
Today's Topics:
1. Re: M3DA protocol proposed as part of initial contribution of
Mihini (Fabien Fleutot)
2. Re: M3DA protocol proposed as part of initial contribution of
Mihini (Mike Milinkovich)
----------------------------------------------------------------------
Message: 1
Date: Thu, 31 Jan 2013 11:09:10 +0100
From: Fabien Fleutot <fleutot@xxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] M3DA protocol proposed as part of initial
contribution of Mihini
Message-ID:
<CAAOFXS-ydosaPs7dh9ze_P_Wbp7YRPVTmWTW+370ZWW==BrLYQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Jan 30, 2013 at 11:33 PM, UOMo <uomo@xxxxxxxxxxx> wrote:
> I find the absense of proper Units disturbing and dangerous. How would the
> receiver of such message kow, if it's 33 kpH or mpH or any other unit?[?]
You definitely need units, but you don't want to pay for them in bandwidth;
they're best kept in the application model, on the server, and there's no
need for the device to repeat them in each message. M3DA is intended for
device <--> backend data transfer. However, it would seem sensible to add
units backend <--> applications communications, indeed.
If we can make the embedded API units-aware without turning it into an
awful mess nor something requiring a PhD to program with, that would be
great as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130131/21d72c23/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 322.gif
Type: image/gif
Size: 100 bytes
Desc: not available
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130131/21d72c23/attachment.gif>
------------------------------
Message: 2
Date: Thu, 31 Jan 2013 10:23:53 +0000
From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Cc: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] M3DA protocol proposed as part of initial
contribution of Mihini
Message-ID: <AE507FD2-0CE5-444D-AB7D-92CC981D4547@xxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Benjamin,
My question is whether the protocol code should perhaps be in Paho? I checked the proposal and its not tied to MQTT.
Mike Milinkovich
+1.613.220.3223
mike.milinkovich@xxxxxxxxxxx
On 2013-01-30, at 9:53 PM, Benjamin Cab? <bcabe@xxxxxxxxxxxxxxxxxx> wrote:
> Greetings,
>
> During our weekly call yesterday, I briefly mentioned the e-mail below that apparently went unnoticed in what was already a pretty long e-mail thread? hence this new thread :)
> We are hoping it can be a good basis for discussion, and we are looking forward to getting the group's feedback on the protocol, and discuss how it can maybe complement MQTT for some use cases during one of our weekly calls and/or in a Paho call. FWIW I won't be able to make it to next week's call, I'll be on the Eclipse Foundation booth at JFokus demoing our technologies!
>
> Cheers,
> Benjamin.
> _________________
> And
>
> Hello all,
>
> It's great to see so much interest in that discussion! As you say Rick, there's probably still lots of efforts to do in order to go a step further in terms of enabling M2M communications, but it's really great to see MQTT moving to OASIS.
>
> I would like to invite you all to have a look at the attached presentation, as well as to the Mihini wiki page [1] where we provide more information regarding the M3DA (Micro-M2M Data Access) protocol that Mihini will rely on for Device and Asset Management. I think it addresses some of the points you raise, Rick...
>
>> - Stronger typing and metadata for payloads
>
> The approach we took is indeed to try to have a serialization model that has strong typing, including the ability to describe data structures usually found in M2M applications (vectors of data, smart handling of timestamped values).
>
>> - Semantics for data, events, services, blob/file and stream content (all essential for a modern M2M platform)
>
> FWIW I think having a protocol that, to some extent, describes the payload is important (see the previous paragraph?), but it is probably complementary with having a separate, more complete, model of the full capabilities of a given M2M application (I am sure you remember the discussions we had about [2] :-)) This model is also kind of crucial to support legacy applications (hence legacy protocols) for which the communication protocol does not allow any sort of typing, discovery, etc.
>
>> - Store-and-forward best practices/reference implementations for occasionally connected devices
>
>
> M3DA features a way to acknowledge correct delivery of messages, and the Mihini agent comes with all the logic needed for not losing data in case of unreliable network connection, as well as the logic needed to communicate only once in a while (a Mihini application can send data to specific queues that get "flushed" to the server according to specific policies: cron table, on-demand, ?)
>
> I'd be happy to hear the group's thoughts on these first elements of information regarding M3DA, and of course there will be more to discuss about when the Mihini source code, hence the reference implementation of M3DA, will actually be available (it's a matter of weeks now, we are still under IP review by Eclipse legal).
>
> Best regards,
> Benjamin.
>
>
> [1] - http://wiki.eclipse.org/Mihini/M3DA_Specification
> [2] - http://wiki.eclipse.org/Machine-to-Machine/M2MIWG/M2M_meta-model
>
> Le 26 janv. 2013
> <M3DA Presentation.pdf>
> _______________________________________________
> m2m-iwg mailing list
> m2m-iwg@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/m2m-iwg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130131/fb63493d/attachment.html>
------------------------------
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
End of m2m-iwg Digest, Vol 15, Issue 18
*************************************** |
