...

...

• Conversational and non blocking + callback programming model over Web2.0 bindings
  Seems like a good fit with JSON for example... in particular Ajax interactions fit really well with the SCA non blocking + callback programming model.

• Ability to model client side JavaScript components
  Looking at the Store sample for example, I'd like to be able to model the client Javascript as a component with SCA references to the ShoppingCart and Catalog services, instead of manually creating JSON and Atom client proxies in the client Javascript code.

• Support for Atom using Apache Abdera
  Abdera just released their 0.3.0, I've started to look at it and it looks pretty good. I think we should try to port our Atom/RSS binding to it and see how it compares with the Rome library which we are currently using.

• More modular distributions, in addition to our current all-in-one distribution, distribute smaller packages that people can choose to install or not?

• Some clean up of the core runtime invocation and injection mechanism, we can probably simplify and actually remove code in a number of places

• Separate the interface declaration (per service or reference) and interface type (can be shared if used by multiple services or references) and enhance the dynamic interface/operation support

• Improve exception handling accross bindings

• Better support the remote case of binding.sca (marshaling/unmarshaling data, performance optimization, propagation of callable references)

• Bring binding.jms to spec 1.0 level (and what about JCA as the 1.0 spec is out?)

• Add support for JSONRPC reference binding so that SCA components can talk to JSONRPC services

• Better align the WSDL2Java tools with Axis2

• Leverage the Axis2 JAX-WS metadata layer for better WSDL/Java interop and the WSDL-less support

• Improve the Eclipse-based tooling support to facilitate developing and testing Tuscany SCA Java applications.

• Further improve the Tuscany/Geronimo integration to better leverage the SCA domain/node

• Website documentation. There's still lots of detail and improvements we could add to the documentation and its really important to attract users

• Resolve JIRAs. Be good if we could all commit to trying to resolve at least a couple of these each week if we're to make much of a dent in the 150
  open ones.

• Fix nightly builds (looks like this may be going again now)

• Fix all the build issues (maven 2.0.6/2.0.7/JDK6/empty repository) so new users building Tuscany have a good experience

• Make releasing easier - things like move to maven gpg and/or release plugin so creating releases doesn't take such an effort

• Distribution improvements - conclude the ML discussion from a while back on the size and ease of use

• Further improve SCA policy support. Good support for things like WS-Security and WS-RM and show using Java/JMS/WS etc and all the QOS stuff really is as easy as just saying something like requires="reliability"

...

• For JMS maybe have a host-jms module so you don't have to start a separate JMS server or can use the the Geronimo one if thats where Tuscany is running

• Get the Geronimo integration and WAR distribution working really well and with all Tuscany extensions so you can take a Tuscany sample contribution jar and it easily runs where ever you deploy it.

• Better integration btw script components and bindings and data bindings to show the dynamic language support really does have value - seamlessly wire up Ruby components using Hpricot for HTML processing with binding.http, JavaScript/E4X for XML manipulation with binding.ws etc

...

• Improve the error reporting/handling for our data binding framework.

...

• Support load contribution as a osgi bundle.

...