Mihini proposal [message #897005] |
Fri, 20 July 2012 18:33 |
|
I am glad to announce the Mihini project proposal.
The main goal of Mihini is to deliver an embedded runtime running on top of Linux, that exposes high-level Lua API for building M2M applications. Mihini aims at enabling easy and portable development, by facilitating access to the I/Os of an M2M system, providing a communication layer, etc.
Mihini is at the heart of the M2M Industry Working Group efforts, together with Paho and Koneki.
Please use this forum topic if you have any questions or input into this project proposal.
Regards,
Benjamin.
My blog: http://blog.benjamin-cabe.com
[Updated on: Fri, 20 July 2012 18:34] Report message to a moderator
|
|
|
|
Re: Mihini proposal [message #901880 is a reply to message #897005] |
Tue, 14 August 2012 21:16 |
|
Hi Pascal!
Really great to see you are interested in Mihini Do you have a specific interest in Mihini other than just curiosity? (put differently, should I add you to the list of interested parties?)
Some answers to your questions:
Quote:- Is the REST API expected to be available in the field, or will it just be a development time item?
The initial purpose of the REST API is about enabling local monitoring and control of the embedded framework.
It is intended to enable the creation of third-party tools easily (provisioning, monitoring, or other kind of development tools).
This REST API may also be used by other process running locally on the target, to get information on the health of the embedded framework, list the contained apps, etc. Given that it might prove difficult to reach/address devices on the field in a direct manner, I don't think it would make that much sense to expose the REST API to the world.
Note that this REST API is not part of the initial contribution but is something we want to work on soon, together with the M2MIWG folks.
Quote:- Will the framework be modular in that it will be possible to deploy only parts of the fwk (e.g. no application management)
Yup, it is modular. It is possible to only build/deploy parts of the framework, or build/deploy the complete framework and have some components disabled by default.
Quote:- Will the device management rely on an existing standard like OMA-DM?
At the moment, Device Management actions are performed using an homebrew protocol but a mid-term goal (as highlighted on the high-level architecture diagram) is to provide a communication/transport layer as protocol-agnostic as possible, thus enabling Device Management over OMA-DM.
Should you have any questions, they'd be most welcomed!
Benjamin.
My blog: http://blog.benjamin-cabe.com
[Updated on: Tue, 14 August 2012 21:17] Report message to a moderator
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05111 seconds