Thanks thats helpful. Let me take this to the extreme so you can point out
where it loses the plot to help me understand what you're saying:
The idea is eventually there might be standardized interfaces for all the
SCA runtime plug points, many of the Tuscany things for the various SCDL and
SPI interfaces - tuscany-assembly, tuscany-spi etc - that right now we have
in org.apache.tuscany.sca namespace might one day be standardized
interfaces, just like the org.osoa.sca.* interfaces for application Java
implementations to use, and there would be a standard way to define new
binidng and implementation extensions in the definitions.xml.
Anyone could make an SCA contribution that would add a binding or
implementation type which once contributed to an SCA domain then other
contributions in the domain could use in their SCA assemblies. And this new
binding contribution would work in any runtime that supported SCA just like
application SCA contributions should.
So as a simple example, say a file binding that component service or
references could use to read and write to a file system. That could be
packaged in a regular jar which has a meta-inf/definitions.xml along the
lines of:
<definitions ... >
<bindingType type="binding.file" ... >
...elements and attributes defining the binding.file schema and
implementation classes ...
</bindingType>
</definitions>
and all the file binding implementation classes within that file binding
contribution jar would implement only standard interfaces, nothing at all
Tuscany specific in the contribution.
The splitting out all the various Tuscany SCDL classes and SPIs points into
interfaces happened when we did the 0.90 rewrite so binding and
implementation type extensions can now be written using only interfaces, but
the pluggablity mechanism is still quite Tuscany specific. So is whats being
suggested with this definitions.xml work starting on the road to coming up
with a less Tuscany specific way of doing that, it would still be in a
Tuscany namespace for now just as the various Tuscany SPI interfaces are,
but in the future all this would be defined in some SCA spec , but it would
just be a refactor in Tuscany to move to that spec namespace instead of a
complete rewrite?
Is that anything like what you had in mind?
...ant
On Thu, May 15, 2008 at 7:32 PM, scabooz <[EMAIL PROTECTED]> wrote:
> I might be the 'they', not sure. This is a very hard email thread to
> follow so let
> me try to articulate some ideas.
>
> First, bindingType and implementationType were introduced by the SCA Policy
> FW spec because that spec was the first to need a bit of metadata
> describing
> bindings from a typing perspective so that policy could be provided by the
> type
> and didn't have to be repeated on every binding instance. Implementation
> types
> was an obvious next stop on the journey. The text was driven into the
> Assembly
> spec as the result of a realization that these two concepts would be needed
> by
> SCA extenders who wish to add bindings and new kinds of components into any
> SCA runtime that was implemented by some another party. The assembly
> spec group decided (rightly IMHO) NOT to dive more deeply into filling out
> these concepts in V1.0. It would be more appropriate to tackle these sorts
> of
> issues in a future revision of the technology.
>
> Second, Tuscany is an open community where the plethora of talent enables
> new innovative ideas to be explored. These extensibility points are a
> great
> place for Tuscany to experiment with different approaches. I think it
> would be
> fantastic if Tuscany could "finish" the work of the spec group and come up
> with
> a reasonable (and workable) model for extensibility and then propose it to
> the
> spec group. Building on this thought then is the assertion that
> bindingType
> is the starting point for 3rd parties to describe a binding implementation
> to a
> runtime not authored by the binding implementer. It would be naive to
> think
> that the current structure of bindingType, it's containment within a
> defintions.xml
> file or any other related aspect is off limits from change in this
> experiment.
>
> I'm not clear on what all the issues are that have been raised. I see a
> lot of
> mis-information and some emotion that's hard to sort through.
>
> I saw a strawman that looked like a good start in one of the emails but
> there
> seemed to be resistance that I didn't understand. The SCA bindingType
> and implementationType concepts have nothing to do with policy. Policy was
> the first functional area that happened to see the need for them.
>
>
> Dave
>
>
> ----- Original Message ----- From: "ant elder" <[EMAIL PROTECTED]>
> To: <tuscany-dev@ws.apache.org>
> Sent: Tuesday, May 13, 2008 2:40 AM
> Subject: Re: [DISCUSS] Declaring extensions as being available in the
> domain
>
>
> On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan <[EMAIL PROTECTED]>
>> wrote:
>>
>> Agreed to all that ONLY IF definitions.xml is going to contain things
>>> related to policies only. Though it is at the present moment my belief
>>> is
>>> that it could evolve to represent information more than just policy
>>> related
>>> things. This belief of mine is based on the following : -
>>>
>>> - the name of the file is 'definitions.xml' and is not
>>> 'policy-definitions.xml'
>>> - this is defined in the assembly model specs and not in the PolicyFwk
>>> specs. If its just for policies, I'd reckon that it would have been
>>> defined
>>> completely in the PolicySpecs and only referred to in the Assembly Model
>>> specs. Right now its vice-versa.
>>>
>>> Maybe some Specs folks should give us their perspective on this.
>>>
>>> - Venkat
>>>
>>>
>>> Those are good points. Especially the last one as its they that ask for
>> this
>> in an offline discussion so it would be really good to get their input
>> here.
>>
>> ...ant
>>
>>
>
