Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gcharters@googlemail.com
 designates 72.14.220.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=W7xgJcj5ZRXvzGXDZWO+h18T8Lzp5VkClD74deykWgDrexGkA/9VO45HMDekBPmnjQ
         QlvUIAYSgsazrTFF0IFxO9j3sRS/2K631iOrFR3nSmeveBEERvR4cvGSpL/SxHFFq6h/
         jTpoQI5ECxsUggXcVzWHBO8hWkayR/yL1orwQ=
MIME-Version: 1.0
In-Reply-To: <a1e060231002250352m432ee572o6163a754d5a9becc@mail.gmail.com>
References: <b23ecedc1002151334p6bf9cffdu36e12b1bd2b5ca5e@mail.gmail.com>
	 <b23ecedc1002181324k1a6b6947l32e7d5bae5ffce9d@mail.gmail.com>
	 <c799186f1002190546u6e185eddh1b399ad49791b503@mail.gmail.com>
	 <b23ecedc1002190552w1dacad05kde7a71044c5b16ad@mail.gmail.com>
	 <345578341002190600j241befc2y93a883fbf14f93a1@mail.gmail.com>
	 <b23ecedc1002190701x21ed099fy33bd1218c697f50d@mail.gmail.com>
	 <345578341002190804t3735976difbe97b433e29cb46@mail.gmail.com>
	 <a1e060231002220224q440f7195seaff559f5a61993a@mail.gmail.com>
	 <345578341002250316t7f99d934g4ef8cb3b1b9e4120@mail.gmail.com>
	 <a1e060231002250352m432ee572o6163a754d5a9becc@mail.gmail.com>
Date: Thu, 25 Feb 2010 13:14:28 +0000
Message-ID: <345578341002250514l9df58dah3a0d66ced6856fe3@mail.gmail.com>
Subject: Re: [DISCUSS] Applications and subsystems
From: Graham Charters <gcharters@googlemail.com>
To: aries-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <david.bosschaert@gmail.com> wr=
ote:
> 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 <gcharters@googlemail.com> wro=
te:
>> Hi David,
>>
>> I think I see it a little differently. =A0If 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'. =A0Take 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. =A0Types 1 and 3 have different
>> rules for defaulting what is shared.
>>
>> Regards, Graham.
>>
>> On 22 February 2010 10:24, David Bosschaert <david.bosschaert@gmail.com>=
 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 <gcharters@googlemail.com> w=
rote:
>>>> I'd been thinking the different sets of manifest. =A0I 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. =A0It therefore seems to make sense to emphasise the
>>>> distinction.
>>>>
>>>> On 19 February 2010 15:01, Guillaume Nodet <gnodet@gmail.com> wrote:
>>>>> On Fri, Feb 19, 2010 at 15:00, Graham Charters <gcharters@googlemail.=
com> wrote:
>>>>>> <snip>
>>>>>> I think what we have so far is the basics of 3. =A0We should aim for
>>>>>> consistency across all three, but I think the sharing policy default=
s
>>>>>> need to remain separate. =A0If we were to choose just one policy, th=
en
>>>>>> we will force the others into expressing a lot of unnecessary
>>>>>> information. =A0We could broaden Application to cover all three, but=
 I
>>>>>> think that would be confusing. =A0Maybe 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. =A0What do you have i=
n
>>>>> mind as to identify those different use cases from a user point of
>>>>> view ? =A0Are 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
>>>>>
>>>>
>>>
>>
>