It would be good to keep this discussion on tuscany-user and not have it
intermingled across the tuscany-user and tuscany-dev lists.
Other comments inline.
Simon
ant elder wrote:
On Feb 15, 2008 10:39 AM, Mike Edwards <[EMAIL PROTECTED]>
wrote:
Folks,
A few observations inline.
Ron Gavlin wrote:
I think consolidating the two SDO implementations under a single
implementation would be good for the entire Apache SDO community. My
concern
would be that no Tuscany SDO features be lost in the transition. The
new implementation should provide most of what I can currently achieve
using both EMF and Tuscany SDO. For example, EMF features like
integrated validation should be
available in the new implementation before the old implementation is
dumped. It might be a good idea to poll the Tuscany SDO community to
identify the EMF features currently being used by Tuscany SDO community. It
might also be interesting to poll the Eclipse EMF SDO 1.0 community and
ask the same question. Maybe many of the existing Tuscany SDO test cases
could be re-written for either 1). the new implementation or 2). the CTS,
to minimize the loss of functionality during the transition.
There is a fundamental tension here which I think it is important to
recognise.
On the one hand, we want to ensure a lively and progressive Apache SDO
community that continually extends the capabilities of SDO to better
suit the needs of users. Innovation is a bit part of this story.
On the other hand, we're trying to promote an open (and open source)
approach to the standardization of the SDO interfaces, to help ensure
consistent implementation of SDO across products both commercial and
open source. There is a JSR and a set of activities taking place in
OASIS for this. Part of that work is to produce an RI and a TCK, open
to all. However, an RI must be just that - an exemplary implementation
of the specification, the whole specification and nothing but the
specification. Similarly, the TCK must be testing compliance of
implementations with the specification, the whole specification and
nothing beyond the specification. This demands limitations on innovation.
So, there is some careful work required in building both forward-looking
innovative capabilities and at the same time creating somewhat rigid RIs
and TCKs, which are inevitably tied to specific versions of a
specification. I think that the proposal to have a second SDO project
in Apache is regarded as one way to approach these conflicting
requirements. It may not be the only way, but at least it would provide
clear dividing lines that both contributors and users can understand
easily.
It will take some careful thought to combine these aspects within one
project in a way that works for all contributors and for all users.
+1. This will be one of the biggest challenges in bringing these two
SDO efforts together.
One of the reasons that Tuscany is NOT an RI and does NOT contain a TCK
for SCA is because it fosters freedom in the implementation of new
capabilities that go well beyond the current SCA specifications. Some
of these will feed into future "standard specifications", I'm sure.
+1. I think it's important to retain this freedom for Tuscany to
innovate and not be constrained to exactly match any particular level
of the specs that it implements.
>From my perspective, the priorities for Apache SDO moving forward should
be:
1. Align Apache SDO with the JAXB specification.
The static SDO implementation should be JAXB-compliant.
2. Align Apache SDO with the JPA specification. It should be simple to
use a OpenJPA to persist SDO graphs.
3. Provide data binding support for popular Java open source WS stacks,
especially Axis2 and CXF.
Yes, all good innovative stuff.
I could toss in a few more, such as having an SDO implementation for
JavaScript to address AJAX applications.
But how to square this with the RI and TCK with fixed functions matching
the SDO 2.1 specification?
Its also important to recognize that Apache is about community and projects
need a scope that is broad enough to foster a community.
To maintain an active community there needs to be something to keep
developers participating after the 2.1.1 RI is done, otherwise why even do
this at Apache? If a goal is to continually extend the capabilities of SDO
and to feed innovation into future versions of specifications then thats
going to work better if there is a single SDO community not communities
split between separate Apache projects.
>
I agree that a sustainable project community would need something beyond
just doing the RI for SDO 2.1.1. This could be to continue as an RI for
future SDO spec levels, or it could be to branch out in innovative ways
beyond any current or in-progress SDO specification. I suspect that
trying to do both of these at the same time would be quite a stretch and
could lead to neither goal being achieved very well. If the proposers of
the new project could indicate which of these they expect to be the main
focus, I think that would be helpful.
Other Apache projects have managed
to produce RIs without splitting the work out into a seperate project so i'm
sure the same could be done here - separate builds or SVN branches or sub
projects under the one SDO TLP.
I'd be interested to know which of the two approaches I described above
has been taken by these other projects. Have any been able to successfully
combine both aspects?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
