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.
Making it easy to publish programmatically any kind of events the developer can think of from their interceptors/application code as
atom feeds would be nice IMHO, the Atom publisher can be just one optional pluggable publisher...
Personally, I'm not quite sure whether the Atom-formatted response can serve as a generic data container for all types of data out
there, this is at least one of the reasons (as far as I understand) Web3S came out...That said, it's an interesting idea
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.
+1 again.
Cheers, Sergey
----- Original Message -----
From: "James Strachan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 07, 2007 5:48 PM
Subject: Re: 2.1 thoughts......
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/
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
