[LEDE-DEV] Recently added feature in UCI - mandatory anonymous sections

[Jo-Philipp Wich]

On 11/08/2016 05:13 PM, Antonio Paunovic wrote:
> Hello everyone,
>
> recently there was a change in default UCI behaviour which you can
> see here:
>
>
http://git.openwrt.org/?p=project/uci.git;a=commit;h=df72af474075159ab79ed190d2109eb2d86709bf
>
>  While change in implementation is minor, this means that there won't
> be anonymous sections anymore. Need may arise to update UCI
> configurations remotely and anonymous sections are inconvenient for
> this use case. Being anonymous they can't be addressed in
> straightforward manner.

What about lazily transforming those unnamed sections into named ones on
the first write performed by such an application? The UCI api could be
extended with a new flag which allows an application to request such a
transformation.

I don't think the config format should be changed in such a way just
because it is inconvenient for your use case. It has been inconvenient
for LuCI as well, yet we didn't propose to simply drop the anonymous
section support.

Also if your application needs unique IDs, why just not add them into
the sections and build appropriate lookup procedures on top of the uci
primitives? Something like

  config unnamed
    option id c43db0ba-a721-11e6-80f5-76304dec7eb7
    option foo bar

This could even become a new keyword "id" instead of option to avoid any
clashes with preexisting values.

> By default, sections would be named automatically and currently there
> is no way to change it. Some concerns were raised regarding how UCI
> is used and why this feature needs to be discussed. There is a
> tendency to open configuration files and manually copy-paste sections
> with similar purposes. Those sections are usually anonymous because
> name would be superfluous. And sometimes there is even an option
> 'name' (or similar) in anonymous sections.
>
> Those are current benefits and concerns but there may be others in
> the wild. We'd like to hear about experience from the community and
> suggestions in order to resolve challenges above. Anybody has any
> thoughts on the subject?

The downsides I see with forcibly naming unnamed sections:

 - It invalidates pretty much all documentation related to anon sections

 - It confronts CLI users with visual noise in the form of unexpected
   random IDs

 - It makes copy-pasting collection-style config sections (such as
   routes for example) harder and more error-prone because users now
   suddenly have to change the unique IDs as well (or risk a brick
   due to semantic errors in the network config otherwise)

 - It makes adding new (anonymous) sections harder as users need to make
   up IDs for them now and ensure that they're unique

 - It breaks the expected output format, there are a lot of scripts out
   there that parse "uci show" output, expecting to find @type[#] style
   identifiers, those would stop functioning as expected


In short, the configs are getting more cumbersome to use for humans just
to solve inconveniences for programmatic access.

~ Jo