I'd love to see AtomPub support as a new kinda front end / binding. http://atompub.org/rfc4287.html
I've had brief conversations in bars in various coutries in the past with DanD about this - previously we looked at some annotations to expose RESTful resources using individual annotations on operations; to bind a specific method/property to a URI etc. Am wondering if an AtomPub binding could be simpler and a little cleverer; as AtomPub automatically understands collections & navigations through types together with the basic operations. e.g. relationships, collections, add/remove/update semantics etc. Another thing I'd like to see is some tooling/maven plugins/whatever so folks can do contract first development, but instead of having to edit WSDL, they could just edit RelaxNG Compact Syntax to define the structure of messages; which then could auto-generate the XSD / WSDL. Or even supply some example XML documents - which by using Trang could then generate the XSD/WSDL. For more background see... http://www.nabble.com/contract-first-using-either-XSD-or-XML-plus-Trang-tf3679800.html#a10288179 On 8/7/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > With 2.0.1 almost out the door (getting votes when everyone is on > vacation sucks), I'd like to take a minute to think about what should go > into 2.1. We've tossed around a bunch of ideas and I'd like to get > them written down. I'll probably start a "wish list" wiki page once > the ideas get flowing, but for now, here's my list of stuff I've seen > floating around: > > 1) JAX-WS 2.1/JAXB 2.1 - this is a fairly large amount of work as there > are some very significant changes that will involve code generation > changes, java -> wsdl changes, runtime support changes, etc.... > > 2) Data bindings - XmlBeans and JIBX have been on the list for a while > and I'm sure more XFire folks could find CXF more useful if we got those > working. There are two parts: runtime and tooling. > > 3) JavaScript stuff - the javascript frontend needs some refactoring to > allow calling other services with it, make it not dependent on the jaxws > frontend, etc.... Also the js donation from Basis Tech would be great > to get wired in. (if we can get the grant set, too many people on > vacation) > > 4) Rest stuff - all the buzzword compatible stuff. :-) > > 5) WS-* specs - do we have time to tackle any more of these at this > point? Which ones should we prioritize? > > 6) OSGI bundling - I think adding simple OSGI manifests for our jars > would be fairly easy. However, should we create some "bundles" to > represent common functionality? (like JAX-WS/SOAP/HTTP bundle) > > > I hate to ask for more ideas as that alone is a TON of work, but at this > point, let's get the ideas flowing. :-) > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] > http://www.dankulp.com/blog > -- James ------- http://macstrac.blogspot.com/
