Move standard custom 'keys' into interface

[bpaauwe]

Like notices, the customparams, customdata, customtypedparams/data could be moved into the interface so that the interface initializes and updates them when these messages arrive from PG3.

This would relieve the node server of having to create globals for these and manage updates via the event handlers.

[Goose66]

We could add the CustomNS as well as a dictionary with the key ("nsdata," <node_address>, and what have you). I do think we have a needlessly large number of different custom types at this point, but I don't know the best way to go through and limit them to the ones actually being used.

[Goose66]

I am just realizing a possible negative ramification of this. If you add Custom objects for these keys ("customData," "customParams," "customNS," "notices," etc. in the Interface, then those will be separate copies of the dictionaries related to these. If the nodeserver has their own updated by subscription to events, and the Interface tries to update one of its own copies (or the nodeserver has inconsistent code and tries to update an Interface copy), the Custom object in the Interface and the Custom object in the nodeserver will get out of sync, and any subsequent updates will make the database out of sync.

[bpaauwe]

Yes, that's true. The node server would have to use one or the other, not both methods of accessing the data. One solution would be to not include the data in the event (which would break existing node servers). But then the event would just notify the node server that the data had changed, it would have to access the interface copy to get the new data.

this may be something that triggers versioning of the interface so that the node server has to pick which API version it wants to use. Existing node servers would get the old API by default, new node servers (or updated node servers) could pick which version they want to use.

[Goose66]

Yeah, with 60 some nodeservers already in the mix, we don't want to do anything to break existing at this point. Another workaround is that a nodeserver can also just retrieve these items from the initial config if it doesn't want to subscribe to all the individual custom message publications. Of course, it won't get configuration parameter updates that way. But this is what I am doing to snapshot _nodes before it gets corrupted by addNode.