Mutability discussion

[m0mus]

On the meeting at 2002-02-17 we agreed that we should try to support proper mutability since Jakarta Config 1.0.

We have three mutability use cases:
https://github.com/eclipse-ee4j/config/issues?q=is%3Aissue+is%3Aopen+label%3Amutability

So far we have the following conceptual suggestions:

• Possibility to get multiple values from the config source in a single request.
• We need a mechanism allowing a config source to notify that configuration is changed. Options: notification and direct call.
• That notification mechanism must be switchable on and off.

This discussion is created as a follow up to our discussion on the meeting. Feel free to add your suggestions and proposed API code snippets here.

[dmlloyd]

I have a few additional starting points for discussion. Sorry I didn't get a chance to post this sooner.

• Should configuration consumers have a mechanism to subscribe to, or express interest in, the notification mechanism? Can this be constrained to subtrees? What could this mechanism look like?
• How should this tie into validation? For example, if a configuration revision is not acceptable to the application, how can the application reject the configuration? Does it simply ignore the configuration or do we need something more formal?
• We talked about using optimistic and pessimistic mechanisms to evaluate the consistency of a configuration. Can we produce an API which allows implementations to choose between these? How might that look? (ideas)
• Can we ensure that a new configuration change is not signaled until the previous change is completely consumed, in order to prevent applications and frameworks from getting into an inconsistent state due to concurrent processing of changes? Can we codify this into the spec?

[ljnelson]

See also: #109