On Tue, Aug 20, 2024 at 12:20:55PM +0000, Jan Lindblad (jlindbla) wrote: > > PS: And with a well designed merge operation, one might in the future > even move towards breaking the monolithic <running> into pieces, > like we do for the <candidate> singleton today. > > [janl] Could you expand on that last PS? I’m not following your train of > thought here. >
If you take the configuration of a web server, then it is common practice to organize the configuration of different sites a server is serving into separate files. (I am talking about modularity of config instance data, not modularity of the underlying data models.) The server then loads the configs of all active sites and merges the settings somehow to derive all the internal settings necessary to provide the configured services. In the NC/RC world, we have a single monolithic <running> and hence all the busy merging needs to happen on the client side or you hope that clients respect each other instead of stepping onto each others toes when they make changes. I can see possible advantages of splitting our monolithic <running> into multiple <running>s that are then merged on the server side into the grand unified <intended>. This gives us modularity, possibly easier to manage access controls, perhaps execution gains if it is possible to localize validations that do not always have to generate and revalidate the grand unified <intended>. I understand that this may sound far reaching since the IETF tends to move sloooowly and to be rightfully conservative about more radical proposals. On the other hand, having a plan where to go with a technology may help to guide current work and to avoid getting stuck with point solutions that at the end make it impossible to evolve beyond a certain stage. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
