[LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

[Daniel Golle]

Hi Felix,

On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
> On 2016-12-01 16:05, Daniel Golle wrote:
> > Hi Sukru,
> > 
> > On Tue, Nov 22, 2016 at 08:52:57PM +0000, Sukru Senli wrote:
> >> Hi Daniel,
> >> 
> >> Regarding (Phase 2 - ubus rpc proxy), I had opened a thread in October: https://lists.openwrt.org/pipermail/openwrt-devel/2016-October/042252.html
> >> 
> >> Currently we are working on a solution where multiple OpenWrt devices share a common ubus which allows us to control all devices from a single point.
> >> 
> >> Our initial development is based on websockets (we have replaced uhttpd with our websocket solution). ACL is still handled by rpcd.
> >> 
> >> Once we are done with the initial development, we are planning to share the code with the community so that anyone who is interested can try it out and provide feedback and/or contribute.
> >> 
> >> As the next step we were planning to investigate another approach where websockets are not used for proxying but instead a lower level ubus proxying, ubus monitor, and ubus ACLs (instead of rpcd) are used.
> >> 
> >> If you agree that we are trying to achieve the same goal here, maybe we should see how we can cooperate.
> > 
> > I was following your posts and do believe there is quite some overlap.
> > It would thus be feasible to generalize the common parts (ubus call
> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared
> > interface the actual implementations shall use. In that way, people
> > can choose whether they want WebSockets, TR-069 or a suitable P2P
> > framework depending on their specific needs.
> > Has anything of your current approach at IOPSYS been made available
> > publicly (eg. on github?)
> > 
> > From what I can tell there is also some overlap with Felix' proposed
> > System Configuration Abstraction Layer, just that my envisioned use
> > exceeds system configuration as it includes sensors, events and actors
> > rather than just access to a configuration model.
> If it makes sense, I'd be open to extending my abstraction layer to make
> it suitable for your use case as well.
> Feel free to propose changes to it if you like.

Having a first deeper look at scal I believe that access to sensors
and actors could be implemented inside scal similar to the existing
shell and system backends. That would be nice, as then scal would
make things available on ubus and provide the ACL mechanics.

I'll have a deeper look and play with it to see whether that can
work.

Ideally, data collection (think: interface counters and such things
which need to be polled) and triggering events (think: link status
updates) should also be made accessible.

A local database which exceeds UCI state as suggested by Luka could
also be very useful, eg. for renewable energy or other applications
where loss of connectivity should never imply loss of collected data.


Cheers


Daniel

> 
> - Felix
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev