Okie would go with SecondaryNodeStoreProvider approach and also have a role property for that. For now this interface would live in plugins package and exported as it needs to be used in oak-segment and oak-segment-tar. Later we can decide if we need to move it to SPI package as supported extension point Chetan Mehrotra
On Wed, Jun 22, 2016 at 4:44 PM, Stefan Egli <[email protected]> wrote: > 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 > >
