On 22/06/16 12:21, "Chetan Mehrotra" <[email protected]> wrote:
>On Tue, Jun 21, 2016 at 4:52 PM, Julian Sedding <[email protected]> >wrote: >> Not exposing the secondary NodeStore in the service registry would be >> backwards compatible. Introducing the "type" property potentially >> breaks existing consumers, i.e. is not backwards compatible. > >I had similar concern so proposed a new interface as part of OAK-4369. >However later with further discussion realized that we might have >similar requirement going forward i.e. presence of multiple NodeStore >impl so might be better to make setup handle such case. > >So at this stage we have 2 options > >1. Use a new interface to expose such "secondary" NodeStore >2. OR Use a new service property to distinguish between different roles > >Not sure which one to go. May be we go for merged i.e. have a new >interface as in #1 but also mandate that it provides its "role/type" >as a service property to allow client to select correct one > >Thoughts? If the 'SecondaryNodeStoreProvider' is a non-public interface which can later 'easily' be replaced with another mechanism, then for me this would sound more straight forward at this stage as it would not break any existing consumers (as mentioned by Julian). Perhaps once those 'other use cases going forward' of multiple NodeStores become more clear, then it might be more obvious as to how the generalization into perhaps a type property should look like. my 2cents, Cheers, Stefan
