Hi Rick, and thanks for the feedback!
A few comments/answers below.
> file transfer (upload log files, download config and software updates)
Configuration and software updates are already handled by the Application Manager of Mihini. Logs can be transmitted on-demand, using FTP.
File transfer in general is made possible by the underlying Lua VM (i.e. LuaSocket), but maybe it would make sense to provide an higher-level API that allows generic file transmission without mandatory knowledge of what protocol (FTP, HTTP, …) will be used on the wire.
> discovery is a MUST. discovery capabilities (data, services, events, etc)
Agreed. In terms of data/events, the Data Manager exposes a data tree that can be monitored for changes. It would be interesting to see how the availability of services could be mapped on such a tree.
> generic framework for change-based notifications (detect changes based on value, deadband, time, etc) and for edge detection of alerts/alarms (numerical ranges, Boolean expressions, etc.)
The initial contribution of Mihini will include a prototype of a monitoring framework that does exactly what you are referring to. It allows to connect custom or predefined triggers (onBoot(), onChange(var), onDate(cron), ...) to custom or predefined actions (sendData(), forceServerConnection(), …). While the "rules" are expressed in Lua at the moment, it'd probably be useful to support other representations.
> store and forward capabilities/qos
The Data Manager allows to put into queues the data to transmit, and associate these queues with policies such as "send immediately", "send at least every hour", "send after 60sec of latency"… Also, prior to being transmitted, a queue can be consolidated (average, min, max, etc.).
> encryption support
The protocol being part of the initial contribution of Mihini will allow encrypted communications, but one thing that should be considered IMO, is how we could address encryption/obfuscation of what is stored on the actual target (data, logs, binaries, …), so as e.g. an application from customer A cannot be accessed/modified/reverse-engineered from a non-allowed customer B.
Hope that gives you more information about what will be part of the initial contribution (note that for some of these features, the APIs are in a provisional state, and will have to be fine-tuned).
On a side note, should I add you to the list of interested parties on the project? :)
Benjamin.