Re: [sca-assembly] issue 243: is default channel configurable? Proposals

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Hi Eric,

Thanks for pointing out the flaw in proposal 1. If we were to go down 
that path then we'll have to fix it. We did discuss this issue on the 
call today, but didn't take a decision as folks wanted more time to 
think. I took an AI to continue discussion on this list and summarize 
(hopefully correctly) the concall discussion here.

I think we need to figure out which direction we want to go: do we want 
to allow one to configure the default channel in a standard portable way 
or not? Disallowing configuration of the default channel in the spec, I 
don't think, is a good idea. Either we say it is undefined (or stay 
silent) OR we specify exactly how it is done.

Mike has made an argument that we ought to provide a standard way to 
configure the default channel (for things like JMS, policies etc.) 
Personally, I could go either way with a slight preference for some 
version of proposal 1. I find the argument, default channel 
configuration is going to be similar to non-default channel 
configuration and therefore providing standard way to do this would 
allow the same tools to configure the default channel without having to 
invent new ways for every implementation, persuasive.

If we decide we want to go with some modified version of proposal 1. 
We'll have to figure out how to conform to the production rules for 
NCName. One choice is to use __DEFAULT__ (as suggested by Eric) or some 
other reserved value (that doesn't include ':', '/' etc). If we do that 
we'll have to figure out whether this reserved value applies only to 
global channels or all channels. Another choice (proposed by Danny) is 
to add another attribute (boolean) called 'default_channel' (or 
something similar).

We informally decided on resolving this issue next week on the concall, 
so please send your opinions/comments on the ML.

Thanks.

-Anish
--

On 11/8/2011 1:39 AM, Eric Johnson wrote:
> Hi Anish,
>
> On 11/8/11 8:52 AM, Anish Karmarkar wrote:
> > I took an AI to provide two competing proposals for resolving issue 243.
> >
> > Proposal 1: allow the default channel to be configurable.
> >
> > In section 5.9 of WD06, add the following --
> > The default domain channel, like any domain channel, can be
> > configured. Configuring the default domain channel requires one to
> > deploy a domain composite containing a channel with the 'name'
> > attribute value set to "/". Note that since the default domain channel
> > always exists, configuring the default domain channel in a running
> > system is equivalent to reconfiguring an existing channel and will be
> > subject to restrictions and conditions imposed by a runtime on
> > reconfiguration of domain channels.
>
> I was wondering whether you'd fall into the trap/pitfall you hit. I
> meant to send you an email reminder about that, but I forgot.
>
> This proposal doesn't work, because channel names are declared as
> "xs:NCName
> <http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName>", and you
> can't name a channel "/". We had an issue
> <http://www.osoa.org/jira/browse/ASSEMBLY-254> about "/" in the names of
> channels.
>
> Perhaps something like this?
> The default domain channel, like any domain channel, can be configured.
> Note that how it is configured is determined by the implementation,
> because it cannot be deployed like other channels ("/" is not a valid
> channel name). Also note that since the default domain channel always
> exists, configuring the default domain channel in a running system is
> equivalent to reconfiguring an existing channel and will be subject to
> restrictions and conditions imposed by a runtime on reconfiguration of
> domain channels.
>
> Or, more simply:
> "This specification does not define any way to configure the default
> domain channel."
>
> [In any spec, what the spec explicitly or implicitly chooses not to
> define is, by implication, left to an implementation. I'm not sure we
> need to bludgeon readers with more words, or that they add value here.]
>
> I think, instead, if we wish for the default channel to have some spec'd
> way to be configured, then we have to come up with some spec'd way to
> name it, perhaps (borrowing from C) such as "__DEFAULT__".
> > Proposal 2: do not allow the default channel to be configured.
> >
> > In section 5.9 of WD06, add the following --
> > Since the default channel always exists, one is not allowed to deploy
> > and configure the default channel using a domain composite. This does
> > not prohibit runtimes from defining implementation-specific ways of
> > statically or dynamically specifying configuration of the default
> > channel.
>
> Given the fact that you cannot, as currently spec'd, name the default
> channel in order to deploy and configure, this new proposal just seems
> like a variation, "configuring the default channel is outside the SCA
> Assembly spec."
>
> > Comments?
> Nope, none.
>
> ;-)
>
> -Eric.
> > -Anish
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org