On Mar 22, 2006, at 10:27 AM, Jean-Sebastien Delfino wrote:
ant elder wrote:
+1 to having a release from me. Having to build Tuscany themselves
does put
people off trying it - first installing maven and svn and
downloading all
the dependencies etc - having a binary download would help a lot.
Not so
much time to May 15th though, we need a release plan...
...ant
On 3/22/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
We have been having a series of discussions recently about project
structure, APIs, extensions, policies for plugins, distributions
and so
on. I think this is a sign that we have started to move beyond
the "code
the core like crazy" phase to a "how do people add stuff" phase.
However, although we have made a lot of progress, I don't think
we're
quite ready for them to do that yet. As can be seen from our
discussions, there are a couple of things that need to settle
down from
both technical and social perspectives.
We have two sessions at JavaOne: a panel on open source SOA and a
BOF
specifically on Tuscany. I think these present a good opportunity to
meet with other like-minded people, show them what we have and
encourage
them to come and participate.
I think it would be good by then to actually have a binary release
available for anyone to download and use. That will lower the
barrier to
entry and hopefully encourage people to contribute extensions,
bindings,
and the like. I also think that working on a release would focus our
discussions both technical and social.
JavaOne is early this year (May 15 IIRC) which is not far away.
I'd like
to suggest we sort out the APIs we were discussing and get the
project
structure set up.
What do you think - is this the right time? Should we work toward
such a
release? What else should be in it?
--
Jeremy
I think this would be good but we may need to focus down a bit more.
+1 from me. Here are a few things that I think would be good to do
for this release:
- refine and simplify our extensibility story, how do people
contribute new bindings and component types, and the necessary
loaders, builders and interceptors/handlers
I'd be interested in helping with this. I think we're going to need
to organize this into a couple of "subgroups" since there is a lot here.
- improve our web services support (still pretty rough at the moment)
- do a first pass at implementing the SCA async / conversational
programming model
I'm also interested in this
- implement a base policy model and define the extensibility
mechanism for people to plug-in new policies
May 15 is really not far away, but if we have enough time I would
also love to show interop with WCF/Indigo, and also an XSLT
component type.
I think it would be good to rank use-cases. Here's may opinion on some:
1. Web services invocation across modules. I don't think we should
touch subsystems at this point since the spec is likely to change.
2. Alternative binding invocations across modules
3. Binding extensibility
4. Indigo interop for stateless sync
5. Implementation extensibility
6. Async and conversations
If I had to prioritize off the top of my head, I'd say p1s to get
those are:
1. Improve Axis web serivces support so our existing web services
invocation story is credible (p1). Not sure how much work we have
here. To me, the value-add of Tuscany would be in 2-4 below, since
there are plenty of other technologies that can do web service
invocations. I just listed it as one since we need to make sure the
basics are covered.
2. Extensibility story
- refactor to stable API for transport binding types (p1) and
hopefully implementation types (p1)
3. Get the loader story in place and basic runtime bootstrap stable (p1)
4. Additional bindings to Axis through integration with Celtix,
particularly ws and JMS
- Basic integration (p1)
- Ability to retarget (p2)
- Dan, would Celtix get us Indigo interop?
The p2 to me are:
1. Async/conversations
- I think we should start work ASAP on this b/c it may cause a
refactor of the core. I would say it is p2 though since I'm not sure
we are going to finish it by May
Jim
-
Jean-Sebastien
