On Tue, Aug 20, 2024 at 5:54 AM Jürgen Schönwälder <[email protected]> wrote:
> 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. > > The <system> datastore is not a functional partition, like virtual WEB servers . The split between system and client is somewhat arbitrary and quite implementation-specific. It does not provide modularity at all. <running> as a datastore is conceptually monolithic, but required to be that way in implementation. Certainly the protocol operations are not required to operate on the entire config at once. I do not see any significant difference between system-created config and traditional client-created config. In modern distributed systems, the system config could actually be (at least partially) client config, even using the exact same operations as a "real" client. The distinction between system and client-created data is no longer relevant. The immutable flag addresses the relevant issues. Andy 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] >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
