[OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT

Wed Jan 11 08:45:36 EST 2017

Hi Lada,

Thank you for your feedback.

The initial goal of this proposal is presenting the idea of adopting a data model structure which addresses the issue 1 given in the proposal and then defining data models based on this structure which addresses issue 2 given in the proposal.

The JSON example given in the proposal was just to demonstrate an example how configuration properties and methods of an entity could be hosted in a single structure and how that structure could be used to generate UBUS objects.

If the idea is embraced by the community, the next step would be diving into the technical details such as should an OpenWrt specific data model structure be designed or should it be based on an existing data model language e.g YANG.

Looking forward to your further feedback as the topic moves forwards.

Regards,
Sukru

________________________________________
From: openwrt-devel [openwrt-devel-bounces at lists.openwrt.org] on behalf of Ladislav Lhotka [lhotka at nic.cz]
Sent: Monday, January 9, 2017 5:14 PM
To: openwrt-devel at lists.openwrt.org
Subject: Re: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT

Hi,

I agree with you analysis and, moreover, I believe that network
management community has gone a long way to provide tools for both areas
that you mention:

* RESTCONF protocol:
  https://tools.ietf.org/html/draft-ietf-netconf-restconf
* YANG data modelling language:
  https://tools.ietf.org/html/rfc7950

RESTCONF (that should become an RFC soon) could be the integrating layer
for configuration and state data, but also for RPCs and asynchronous
notifications.

YANG is not exactly JSON but close, and it is IMO quite a poweful
language for this domain.

In the long run, it might also help in implementing standard data models
in OpenWRT. These models are currently being developed not only in IETF
but also in IEEE, BroadBand Forum, and elsewhere.

I will be happy to help with this stuff.

Cheers, Lada

-------- Forwarded Message --------
Subject: [OpenWrt] Data_Model_Structure_Proposal_for_OpenWRT
Date: Mon, 9 Jan 2017 11:22:45 +0000
From: Sukru Senli <sukru.senli at inteno.se>
To: openwrt at lists.prplfoundation.org <openwrt at lists.prplfoundation.org>
CC: openwrt-devel at lists.openwrt.org <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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel