On Mon, Aug 15, 2016 at 9:46 AM, Andrew Stitcher <[email protected]> wrote:
> On Sat, 2016-08-13 at 11:49 -0400, Matt Broadstone wrote: > > ... > > > However this can only happen if the linear/legacy stores are > > > modified > > > to use the API it exposes, as otherwise there would be two store > > > plugins vying for the exclusive right to be a store using that > > > plugin > > > API. > > > > > > > > I actually don't think this is correct. I believe the linear/legacy > > stores > > don't use the store plugin (or its interfaces) at all. > > I think you misunderstood what I meant - the linear/legacy store > currently use the same exclusive API that the store plugin does, and so > they cannot be loaded into the qpidd process at the same time as any > other store (even each other). To change this (which strikes me as a > good plan) they will need to be changed to use the store plugin API not > the lower level exclusive API. > > The store plugin cannot be built into the qpidd executable until this > happens or those plugin stores would never be able to be loaded as > their exclusive API would already be taken by another piece of code. > > If I remember correctly the current Linux plugins are written as a thin > API layer on top of the real journalling code so changing the way they > interface to qpidd might not be too difficult (but someone would need > to actually do it). > > Andrew > > Ah yes, this is my understanding as well sorry for the confusion. It's also my understanding that, in general, there's a requirement than any given store plugin be loaded one at a time (though you're correct that it seems the two windows plugins may be loaded simultaneously). I think what I'm really getting at here is if there is any downside to converting the store plugin to a shared library, rather than a cmake module, and linking each plugin that currently requires it directly to it - rather than passing arguments like: `--load-module store --load-module my-custom-store-plugin`? The existing windows mssql plugins seem to depend on undefined behavior in cmake, in that a `MODULE` target is built exactly like a `SHARED` target. That's what I've done in my local code and it seems to work just fine, just wanted to make sure I wasn't inadvertently breaking the windows path. Unfortunately, I don't think I'll have the time to take over the store plugin refactor you're discussing, but I do agree that it sounds like the right way to go in terms of consistency and helping future implementors. Matt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
