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 >>>>> >>>> >>> >> >
