Hi Stefan, I agree notifications can't reasonably be left to the user to implement. Good to see that notification support is considered and on the map.
Regarding the table at [1], I think OSGI configurations do already support notification (but not inheritance) thanks to [0] and also thanks to updating the related component upon config change. Regards, Timothee [0] https://osgi.org/javadoc/r4v42/index.html?org/osgi/service/cm/ConfigurationAdmin.html [1] https://wcm-io.atlassian.net/wiki/x/BQBLAQ 2016-07-22 12:51 GMT+02:00 Stefan Seifert <[email protected]>: > hello timothée. > > yes, this is E5 from the usecase list > https://wcm-io.atlassian.net/wiki/x/BQBLAQ > > it has do be done right if added, because doing observation-based > notifications in a complex scenario with configuration inheritance, default > values, overrides etc. can quickly become a performance problem. but the > goal of the architecture should be to support it. > > stefan > > > >-----Original Message----- > >From: [email protected] [mailto:[email protected]] On > Behalf > >Of Timothée Maret > >Sent: Friday, July 22, 2016 11:56 AM > >To: [email protected] > >Subject: Re: [RT] Use cases for content-specific configurations in Sling & > >Contribution > > > >Hi, > > > >This looks great! > > > >I think the support for configuration change notifications may be worth > >considering. > >For instance content distribution could leverage it in order to manage its > >endpoints whenever a config change. > > > >Without notifications, a consumer can either I. periodically poll the > >configs to check for change or II. rely on observations in order to be > >notified. > >None of them is ideal, indeed: > > > >I. imposes a lag in discovering the change and adds periodical background > >read operations to the repository which should be avoided if possible > >II. requires the consumer to know about the content structure and know > >about the resolution mechanism > > > > > >If adding this feature slows the process of getting a config mechanism in > >Sling, the notification support could surely be added later on. > > > >Regards, > > > >Timothee >
