I guess I wasn't thinking so much about increments or exceptions to the default. I was more thinking that the override would be a complete redefine rather than a tweak. I guess I see your point a bit better now. It might be worth working out a few use cases to see whether tweaking the default is much better than simply redefining the behaviour.
Thanks, David On 25 February 2010 13:14, Graham Charters <[email protected]> wrote: > I think for the 'deviation' model to work, each statement needs to be > a small incremental progression from the default. I don't yet see how > that would work. If I have an "all shared" subsystem (type 1), then > the small increment is to prevent something, whereas, if I have an > "explicitly shared" subsystem (type 2), then the small increment is to > allow something (would need to be a different header). I don't think > we should be allowing any statements about sharing in "application > subsystems" (type 3). > > Maybe you could give me a bit more detail on how you seen the > increments working? > > Regards, Graham. > > On 25 February 2010 11:52, David Bosschaert <[email protected]> > wrote: >> Right, the defaults would be different, but I guess there should be a >> way to deviate from the defaults. Would it not make sense to use the >> same syntax in use cases 1/3 to describe the deviation from the >> defaults to what you are using in use case 2? >> >> What I'm thinking is: nothing specified -> defaults >> something specified -> overrides defaults >> >> I don't fully understand why you would use different configuration >> settings for this in options 1/3 just yet... >> >> Cheers, >> >> David >> >> On 25 February 2010 11:16, Graham Charters <[email protected]> wrote: >>> Hi David, >>> >>> I think I see it a little differently. If we try to common up the >>> headers, then we end up with a matrix of rules for which headers are >>> allowed on which type of 'subsystem'. Take the example you gave >>> below; for the three types of subsystem I described earlier, only the >>> second type (Explicitly shared) would ever make statements about the >>> services that are exported or imported. Types 1 and 3 have different >>> rules for defaulting what is shared. >>> >>> Regards, Graham. >>> >>> On 22 February 2010 10:24, David Bosschaert <[email protected]> >>> wrote: >>>> I'm not entirely sure what you're thinking yet, could you maybe give >>>> us an example? >>>> >>>> I would imagine that configuration entities with the same meaning >>>> would be configured in the same way across the different types. So you >>>> define the services that you're exporting using the same header/tag, >>>> whether this is a subsystem or an application. Or do you see this >>>> differently? >>>> >>>> Best regards, >>>> >>>> David >>>> >>>> On 19 February 2010 16:04, Graham Charters <[email protected]> >>>> wrote: >>>>> I'd been thinking the different sets of manifest. I think the way >>>>> these types of subsystems will be used will be quite different and >>>>> subsystem definitions will typically not morph from one type to >>>>> another. It therefore seems to make sense to emphasise the >>>>> distinction. >>>>> >>>>> On 19 February 2010 15:01, Guillaume Nodet <[email protected]> wrote: >>>>>> On Fri, Feb 19, 2010 at 15:00, Graham Charters >>>>>> <[email protected]> wrote: >>>>>>> <snip> >>>>>>> I think what we have so far is the basics of 3. We should aim for >>>>>>> consistency across all three, but I think the sharing policy defaults >>>>>>> need to remain separate. If we were to choose just one policy, then >>>>>>> we will force the others into expressing a lot of unnecessary >>>>>>> information. We could broaden Application to cover all three, but I >>>>>>> think that would be confusing. Maybe there are other forms of >>>>>>> subsystem for the different sharing policies, where each is >>>>>>> specialized for the useful defaults. >>>>>> >>>>>> I agree with having different default policies. What do you have in >>>>>> mind as to identify those different use cases from a user point of >>>>>> view ? Are you thinking about completely different set of manifest >>>>>> headers ? Or simply one which would contain the "kind" of >>>>>> application/subsystem defined ? >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> Open Source SOA >>>>>> http://fusesource.com >>>>>> >>>>> >>>> >>> >> >
