Responses inline...for some reason my email client is mishandling the
formatting, so I'll mark my responses with <dab> </dab>
Dave
----- Original Message -----
From: ant elder
To: scabooz
Cc: tuscany-dev@ws.apache.org
Sent: Tuesday, May 20, 2008 2:03 PM
Subject: Re: [DISCUSS] Declaring extensions as being available in the domain
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.
<dab> Yes, that is the idea/theory. </dab>
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.
<dab> yes </dab>
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.
<dab> Good. Only thing to add at this point is that the spec might decide
that the "jar" should be an OSGI bundle. Would such a estriction help, or get
in the way? </dab>
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?
<dab> Bingo. </dab>
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
