Hello Matt, Please find my replies inlined.
> On 4 Oct 2017, at 00:13, Matt Ryan <[email protected]> wrote: > >> 1. Create new BlobStoreProvider interface, with just one method: >> getBlobStore(). >> 2. Modify all the existing blob store services adding them an optional >> “role” property (any string). > One concern I have with this approach is that if we want a data store to be > usable as a CompositeDataStore delegate, that data store has to make > specific provisions to do this. My thinking was that it would be > preferable to have the CompositeDataStore contain as much of the logic as > possible. Ideally a data store should work as a delegate without having to > make any changes to the data store itself. (Not sure if we can achieve > this, but…) Could you elaborate on what kind of provisioning is required for the delegatees? From what I understand, you didn’t plan to rely on OSGi to get the delegate data stores, but initialise all of them in the CompositeDataStore (“contain as much of the logic as possible”). I’m not sure if this is a right approach. It means that composite data store have to depend on every existing blob store and know it internals. If something changes in any blob store, the composite data store have to be updated as well. For the data stores with a rich configuration (s3DataStore) this may get quite complex. On the other hand, the OSGi-based approach makes the whole thing simpler, less coupled, extensible and easier for the maintenance. CompositeDataStore doesn’t need to know any concrete implementation, but rely on the BlobStore interface, without knowing the implementation. OSGi will take care of providing the already-configured delegatees. >> 3. If the data store service is configured with this role, it should >> register the BlobStoreProvider service rather than a normal BlobStore. >> 4. The CompositeDataStoreService should be configured with a list of blob >> store roles it should wait for. >> 5. The CompositeDataStoreService has a MANDATORY_MULTIPLE @Reference of >> type BlobStoreProvider. >> 6. Once (a) the CompositeDataStoreService is activated and (b) all the blob >> store providers are there, it’ll register a BlobStore service, which will >> be picked up by the node store. > I have concerns about this part also. Which blob store providers should > the CompositeDataStoreService wait for? > > For example, should it wait for S3DataStore? If yes, and if the > installation doesn’t use the S3 connector, that provider will never show > up, and therefore the CompositeDataStoreService would never get > registered. If it doesn’t wait for S3DataStore but the installation does > use S3DataStore, what happens if that bundle is unloaded? As above, the CompositeDataStore won’t wait for any particular implementations, but for the BlobStoreProvider configured with an appropriate roles. It knows the role list, so it can tell when all the roles are in place. For instance, we can configure CompositeDataStore with following role list: local1, local2, shared. Now, in the OSGi we’re configuring two FileDataStores, named “local1” and “local2” and also a S3DataStore named “shared”. CompositeDataStore will be notified about all the data store registrations and as soon as three data stores are in place, it can carry on with its initialisation. > Wouldn’t this approach require that every possible data store that can be a > blob store provider for the composite be included in each installation that > wants to use the CompositeDataStore? No. The CompositeDataStore will only reference the BlobStoreProvider interface, not the actual implementations. It’ll be even possible for the customer to implement a completely new blob store implementation and use it as a delegatee (as long as he implements the BlobStoreProvider). Not that we expect customers to do that, but this kind of decoupling makes it easier to work on the Oak codebase. Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com [email protected]
signature.asc
Description: Message signed with OpenPGP
