My $0.02: XFire and CXF are different web stacks, we don't need to import anything from them, unless IONA or another supporting company has a business need to work with XFire. XFire is basically yesterday's news, and as for web service stack incompatibilities--they exist between all web service stacks anyway, even CXF and Metro.
If we were to say that CXF, by virtue of the fact that a few years ago it was based on XFire, needs to still be saddled with that product now and forever more, then we would be putting CXF at a disadvantage of other products, which, blessed with not having anything to do with XFire, can concentrate on moving forward with more modern[1] concerns. OTOH, if there are *small* changes that could bring in lots of XFire users, sure, that would be a good idea. It's really a cost-benefit issue on each change. Another concern is that developers, whether paid or volunteer, cannot generally afford to work with yesterday's technologies--we don't want two-week notices from anyone or dropped volunteers as a result of saddling people with maintaining yesterday's stuff. Regards, Glen [1] http://weblogs.java.net/blog/kumarjayanti/archive/2008/09/support_for_pro.html Benson Margulies-4 wrote: > > I am queasy about adding code to CXF that enables, even optionally, > XFire 'bug-for-bug' compatibility. Somehow, it feels like a bad thing > to enable/encourage the deployment of code that purports to conform to > a standard but does not. A service configuration that warps the JAX-WS > behavior, for example. What do other people thing? > -- View this message in context: http://www.nabble.com/-DISCUSS---XFire-compat-tp19502447p19503459.html Sent from the cxf-dev mailing list archive at Nabble.com.
