Hi Mike, Thanks for the heads-up. Let us see whether the Assembly TC does the same this time too with the proposal to add a top level interface element.
++Vamsi On Thu, May 15, 2008 at 6:07 PM, Mike Edwards < [EMAIL PROTECTED]> wrote: > Vamsavardhana Reddy wrote: > <snip> > >> For 1, 2, 3 and 5, I think it is a good idea to introduce a new interface >> definition as a top level element in SCDLs. This new interface definition >> could use any existing interface definition and add additional semantics. >> For example, something like >> <interface.xxx name="myConversationalInterface" >> interface="myNonConversationalInterface" conversational="true"> >> <operation name="method1" endsConversation="true"/> >> </interface.xxx> >> >> can yield a conversational interface "myConversationalInterface" from a >> non-conversational interface "myNonConversationalInterface". This should >> work as if there were annotations on the original interface definition. >> With >> this new interface definition in place, we may not need "conversational" >> intent on service or reference and "myConversationalInterface" can be used >> whereever "myNonConversationalInterface" were to be used along with a >> "conversational" intent on the service or reference. >> >> Please comment if any of the above does not make sense or suggest any >> alternative ways to deal with these issues. >> >> ++Vamsi >> > <snip> > Vamsi, > > Simon has given a good comprehensive response to your main points - I would > like to focus on this final suggestion. > > You will meet some substantial opposition in the spec group to the idea of > creating a new SCDL-based interface definition language. The group has > rejected such suggestions more than once in the past. > > The argument is that there are already very good interface definition > languages available - and that where SCA extensions are necessary, they can > be added as extension annotations to those existing languages. Providing > yet another parallel interface definition language simply adds to the > complexity of SCA without a corresponding benefit. I believe that all the > issues you raise are already covered by the specs - or there are open issues > awaiting resolution. > > You are welcome to make suggestions to the SCA specification group, of > course, but I thought it useful to give you a heads-up on the likely > reaction. > > > Yours, Mike. >
