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