[LEDE-DEV] Fwd: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT

[Weedy]

For exposure

---------- Forwarded message ----------
From: "Sukru Senli" <sukru.senli at inteno.se <mailto:sukru.senli at inteno.se>>
Date: 9 Jan 2017 6:22 a.m.
Subject: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT
To: "openwrt at lists.prplfoundation.org 
<mailto:openwrt at lists.prplfoundation.org>" 
<openwrt at lists.prplfoundation.org <mailto:openwrt at lists.prplfoundation.org>>
Cc: "openwrt-devel at lists.openwrt.org 
<mailto:openwrt-devel at lists.openwrt.org>" 
<openwrt-devel at lists.openwrt.org <mailto:openwrt-devel at lists.openwrt.org>>

Dear OpenWrt community,

As we know OpenWrt is gaining popularity among industry players, 
especially in residential gateway world. Being one of these industry 
player who has been developing OpenWrt based software for over five 
years now and being a devoted user of the two core components, UBUS and 
UCI, as Inteno, we see two obstacles in OpenWRT on its’ way to be the 
undisputed choice for the majority of the gateway vendors:

Configuration of an entity and data collection from the same entity 
cannot be achieved via single object:
-------------------------------------------------------------------------------------------------------------------------------------------------
For any on-top applications Inteno or third party developers build 
(WebGUI, remote applications etc.) we have to interact with both UBUS 
and UCI (libuci or uci object on ubus) to be able to control a single 
entity. This makes it more difficult for developers as they have to know 
not only what ubus objects but also what uci files and sections they 
must interact with, and interacting with two components increases the 
number of the code they have to write. It also makes it quite 
complicated in terms of access control towards an entity of the software.

There are no ubus data models defined for controlling the entities:
--------------------------------------------------------------------------------------------
If there were data models defined for how to configure/control the 
different entities of the software (network, wireless. voice etc.), any 
application built on top of this data model would seamlessly work across 
different platforms and OpenWRT based systems as long as the 
applications controlling these entities were following the data model. 
Moreover, a defined data model for ubus based on a data model structure 
which addresses the first problem, UCI would no longer be mandatory 
which makes OpenWRT much easier to adapt to for many vendors out there.

We believe the solution to these problems would be developing a data 
model structure towards OpenWRT's ubus with features such as:
- JSON based, well formatted, easy to use/understand
- supports auto code and document generation
- contains version, properties (configuration), methods, valid data 
types/ranges, error codes per object
- allows configuration, data collection and actions within the same 
object as opposed to OpenWRT today where ubus methods + UCI (using ubus 
uci object or libuci or /sbin/uci directly) are used.

Supporting such a data model structure, the ultimate goal would be to 
create an OpenWrt data model to be standardized (ubus objects for 
controlling network, wireless, voice etc.) in order to achieve 
compatibility across different OpenWrt based systems.

IN THE ATTACHMENT, you will find the proposal in PDF format with more 
technical details and examples.

We believe this is a crucial step, when taken, will facilitate the 
adaptation of OpenWrt for the device vendors who are hesitant to it now 
as well as for application developers who depends on the availability of 
certain objects because they will not have to maintain different 
versions for different OpenWrt based systems.

Thank you for your attention and looking forward to your feedback.

Regards,
Sukru Senli
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org <mailto:openwrt-devel at lists.openwrt.org>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel 
<https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Data_Model_Structure_Proposal.pdf
Type: application/pdf
Size: 189509 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170111/d3048f60/attachment-0001.pdf>