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...
/js 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
