The URL defined by the node, used for example in its versions endpoints, should have a single source of truth: the registry.
On startup, the node could fetch the registry listing and use that as the ocn.node.url property. If unlisted it is set to http://localhost:8080.
The node should therefore also be able to PUT credentials on connected party servers to notify that a change in the url has taken place, allowing the connected parties to request updated OCN Node endpoints.
A related point to consider, is that if a new custom OCPI module is added to the OCN Node (like with OcnRules), the Node could also trigger PUT credentials on its connected parties, allowing them to fetch the endpoint of the new custom module automatically.
Original report by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).
The URL defined by the node, used for example in its versions endpoints, should have a single source of truth: the registry.
On startup, the node could fetch the registry listing and use that as the
ocn.node.urlproperty. If unlisted it is set tohttp://localhost:8080.The node should therefore also be able to PUT credentials on connected party servers to notify that a change in the url has taken place, allowing the connected parties to request updated OCN Node endpoints.
A related point to consider, is that if a new custom OCPI module is added to the OCN Node (like with
OcnRules), the Node could also trigger PUT credentials on its connected parties, allowing them to fetch the endpoint of the new custom module automatically.