I think I'm fine with that. Is the enum type return dynamically at runtime. So the API would be something like "PlugInPriority canHandle(...)"?
Darren On Wed, Oct 9, 2013 at 1:13 PM, SuichII, Christopher <chris.su...@netapp.com> wrote: > I think I'll look into a version of (2). The difference being that I think > using an int is too large of a range and provides unnecessary granularity. If > two strategies or providers both have snapshot strategies, they are both > simply going to return the max int. However, if we use an enum with values > like: > > HIGHEST, PLUGIN, HYPERVISOR, DEFAULT and NO, (HIGHEST would be reserved for > unforeseen future use, testing, simulators, etc.) > > then we allow strategies and providers to fall in the same bucket. All > strategies and providers would be sorted and asked to handle operations in > that order. Ultimately, this requires that plugins do their best to determine > whether they can actually handle an operation, because if two say they can, > there is no way for the MS to intelligently choose between the two. > > -- > Chris Suich > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Oct 4, 2013, at 6:10 PM, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > >> Sure, I'm open to suggestions. Basically I think we've discussed >> >> 1) Global Setting >> 2) canHandle() returns an int >> 3) Strategy has an enum type assigned >> >> I'm open to all three, I don't have much vested interest in this. >> >> Darren >> >> On Fri, Oct 4, 2013 at 3:00 PM, SuichII, Christopher >> <chris.su...@netapp.com> wrote: >>> Well, it seems OK, but I think we should keep on discussing our options. >>> One concern I have with the global config approach is that it adds manual >>> steps for 'installing' extensions. Each extension must have installation >>> instructions to indicate which global configurations it must be included in >>> and where in that list it should be put (and of course, many extension are >>> going to say that they should be at the front of the list). >>> >>> -Chris >>> -- >>> Chris Suich >>> chris.su...@netapp.com >>> NetApp Software Engineer >>> Data Center Platforms – Cloud Solutions >>> Citrix, Cisco & Red Hat >>> >>> On Oct 4, 2013, at 12:12 PM, Darren Shepherd <darren.s.sheph...@gmail.com> >>> wrote: >>> >>>> On 10/04/2013 11:58 AM, SuichII, Christopher wrote: >>>>> Darren, >>>>> >>>>> I think one of the benefits of allowing the priority to be specified in >>>>> the xml is that it can be configured after deployment. If for some reason >>>>> two strategies or providers conflict, then their priorities can be >>>>> changed in XML to resolve the conflict. I believe the Spring @Order >>>>> annotation an be specified in XML, not just as an annotation. >>>>> >>>>> -Chris >>>>> >>>> >>>> I would *prefer* extensions to be order independent, but if we determine >>>> they are order dependant, then that is fine too. So if we conclude that >>>> the simplest way to address this is to order the Strategies based on >>>> configuration, then I will add an ordering "global configuration" as >>>> described at >>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions. >>>> >>>> Does the order configuration setting approach seem fine? >>>> >>>> Darren >>> >
