[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] [OpenWrt] [LEDE-DEV] [OpenWrt-Devel] Project pro
Re: [GNUnet-developers] [OpenWrt] [LEDE-DEV] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
Thu, 1 Dec 2016 16:12:38 +0100
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
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:
>> 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.