On Mon, Aug 10, 2020 at 1:56 PM Juergen Schoenwaelder < [email protected]> wrote:
> There are generic preprocessors such as good old cpp or m4 that can do > wonderful things if there is a need to split large (YANG module) files > into smaller pieces. The question here is what the added benefit is to > build sub-modules into YANG itself. The argument I have heard is that > this allows separate compilation of the sub-modules but even then I am > not sure how well this works in practice and whether it is worth to > save some CPU or IO time on developer machines. Perhaps someone can > post concrete numbers that show the savings that can be obtained... > > It is not possible in YANG 1.1 to compile a single submodule. YANG allows the use of identifiers from other submodules without any include-stmts. It is not possible to compile (or read) a single submodule without the main module and all the correct revisions of the other submodules. In this way submodules make readability much worse than imported modules. > /js > Andy > > On Mon, Aug 10, 2020 at 08:08:02PM +0000, Sterne, Jason (Nokia - > CA/Ottawa) wrote: > > Thanks Tom. > > > > Versioning in current YANG specs and in the new versioning work has > independent versioning available for modules and for sub-modules. The > module version will always bump when something changes in a submodule, but > each submodule has its own revision. So it can help consumers quickly see > which parts of a large schema have and haven't changed. > > > > I agree that certain ways of dividing up modules, using groupings, etc > can help or hinder readability. But I think that is orthogonal to > submodules. YANG authors can make good or bad (*) readability decisions in > a schema with submodules or a schema without submodules. If a schema is > divided up at the top level of a tree into submodules, then that is just as > readable IMO as a large data model being divided up the same way into > individual modules. i.e. you can have your bgp module, your interfaces > module, etc OR you can have your bgp submodule, your interfaces submodule, > etc. > > > > (*) good vs bad is often pretty subjective and there are sometimes > tradeoffs amongst readability, consistency, maintainability, etc. But again > that is all orthogonal to submodules vs modules IMO. > > > > Rgds, > > Jason > > > > > -----Original Message----- > > > From: tom petch <[email protected]> > > > Sent: Monday, August 10, 2020 5:23 AM > > > To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; Mahesh > > > Jethanandani <[email protected]>; [email protected] > > > Subject: Re: [netmod] submodules the hidden benefits > > > > > > From: netmod <[email protected]> on behalf of Sterne, Jason > (Nokia - > > > CA/Ottawa) <[email protected]> > > > Sent: 07 August 2020 22:40 > > > > > > I agree submodules can cause confusion, but I also agree with Mahesh > that > > > they can be useful to partition things for people using the modules. > Especially > > > for huge models (e.g. router vendor models). You can jump right to a > > > subsection of the data (a bit like a document with chapters rather > than one > > > huge chapter). > > > > > > It can also be useful for consumers of the models for versioning (when > you > > > want to avoid multiple namespaces). If a model is made up of 30 > sub-modules, > > > it might be useful to know that the "bgp" part changed while the other > parts of > > > the model didn't. > > > > > > <tp> > > > > > > Jason, > > > > > > Jan commented earlier that versioning happens at the module/namespace > level > > > in which case it would seem to me that all submodules will by > definition have > > > the same version so you cannot tell which submodules have changed,, > > > > > > I think too that there is a fallacy in the belief that dividing up > something large > > > makes it easier to use, understand etc. Divide up code by procedure, > > > subroutine etc and if you can provide a parameter or two input, and > one or two > > > results output, and all the complexity of data structures, validation, > algorithms > > > etc and hidden out of sight, then you have simplified. But DDL is > not like that. > > > With a grouping or submodule, you need to know the internals, of what > objects > > > there are, how they are structured, what semantics they have, pretty > much > > > everything inside; it is just harder to find, to reference, to access > because it has > > > been wrapped up in something that gets in the way and tucked out of > sight in > > > some part of the I-D, > > > Rather simplification comes from having the right structure in the > model, which > > > some WG are good at, > > > > > > Tom Petch > > > > > > Jason > > > > > > From: netmod <[email protected]> On Behalf Of Mahesh > Jethanandani > > > Sent: Wednesday, August 5, 2020 6:43 PM > > > To: [email protected] > > > Subject: Re: [netmod] submodules the hidden benefits > > > > > > A contrarian view: > > > > > > I find the use of sub-modules helpful when I want to use separate > files to > > > maintain part of the module that is logically separate, while > > > maintaining/restricting the use of them to a single namespace. > > > The fact that tools have a problem with trying to compile a sub-module > can be > > > addressed in the tools themselves. > > > > > > > > > On Aug 5, 2020, at 2:44 PM, Reshad Rahman (rrahman) > > > <[email protected]<mailto:[email protected] > > > etf.org>> wrote: > > > > > > Indeed > > > https://github.com/netmod-wg/yang-next/issues/26 > > > > > > On 2020-08-05, 5:22 PM, "netmod on behalf of Vladimir Vassilev" > <netmod- > > > [email protected] on behalf of vladimir@lightside- > > > instruments.com<mailto:netmod- > > > [email protected]%20on%20behalf%20of%20vladimir@lightside- > > > instruments.com>> wrote: > > > > > > On 05/08/2020 18.48, Juergen Schoenwaelder wrote: > > > > > > > > > I personally meanwhile believe that sub-modules add complexity with > > > little extra value but this view surely is not shared by others. > > > > > > +1. IMO removing sub-modules from YANG 2.0 should be on the list of > > > proposed changes. > > > > > > /Vladimir > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected]<mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected]<mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
