On Jan 30, 2014, at 1:38 PM, Chris Geer <[email protected]> wrote:
> On Thu, Jan 30, 2014 at 11:05 AM, Daniel Kulp <[email protected]> wrote: >> >> The reason #2 is important for this conversation is that if the PMC >> decided to include hawt.io (providing the skinning/branding is fixed), it >> would also HAVE to include any other third party console that met the same >> requirements. It must be fair and unbiased. Thus, if I fork hawt.io, >> remove the fuse stuff, add some Talend stuff, and publish that, ActiveMQ >> would also have to ship that if asked. If Johan took the current console, >> forked it, cleaned it up a bit, and released as open source, we'd have to >> include that as well. Etc.... I don't know about you, but in my opinion, >> shipping 5 consoles would be confusing to people (and result in a gigantic >> bloated download). >> > > Not trying to pick a fight, just trying to understand this point of view. > Couldn't the same argument be made of any 3rd party library that is used > then? For example, in Karaf, someone could say that they think we should > use something other than pax-url (not an apache project) for url handler > support and Karaf would have to then support that? I agree a project should > be fair and unbiased but I'm not sure that equates to not being able to > officially support one console (if the PMC can control it to a reasonable > fashion). I do think it would be bad if a project were to make it > impossible to replace a component, that would be biased, but they should be > able to say they officially support one approach. There’s a few other “caveats” that would fall into play that should likely be mentioned. For one, someone in the community would need to be willing to make it happen or a patch needs to be provided to get it there or similar. Someone cannot just show up and say “you have to use this jar, but it’s going to take you 500 man hours of work to do it”. Second, which is related, is that it has to be technically feasible within the confines of what the project does. More on this in a second. Third, there are the legal things like license requirements, notice updates, etc… Fourth, there are the trademark/branding things. Etc… For the Karaf case, if someone in the Karaf community did have a different URL handler that would work and it could pass the various tests and such for Karaf and they’re willing to submit a patch or something to get it in there, then yes. Some more concrete examples: 1) In Camel, how many different ways are there to do SOAP even though we all know CXF is the best option? ;-) REST? HTTP? etc… 2) CXF now has 3 different HTTPConduit implementations: URLConnection based, Apache HTTP Async Client based, and a Netty based one. There are also multiple “standalone http server” options including Jetty and Netty and JAX-WS based Grizzly project. PERSONALLY, I don’t see the point of the Netty based one as it has a bunch of scalability issues, streaming issues, not tested as well, etc…. However, someone on the PMC decided they wanted it and were willing to do the work to get it in. Scratch their own itch kind of thing. Could it be confusing for the user to have 3? Yes. However, it's also helping the Netty community flush out bugs, make enhancements that could fix some of the CXF issues, etc…. so the situation is improving. There COULD have been a fourth option. (this is the technically feasible thing I mentioned) The Jetty folks contacted me about creating a Jetty client based HTTPConduit based on the Jetty 9 client API’s. However, CXF supports Java 6 and Jetty 9 requires Java 7 so there was a technical hurdle there that no one on either side was willing to spend time on. Thus, we only have 3 for now. When support for Java 6 is dropped, I expect this to come up again. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
