On Thu, Jan 30, 2014 at 3:16 PM, Daniel Kulp <[email protected]> wrote:
> > 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. > Dan, the CXF example is a great example. Based on that example I think you'd have to argue for keeping both the old console (if there was at least one PMC member willing to support it) and also including hawt.io (if there was at least one PMC member willing to support it). Granted, all the caveats have to be met, which in this case they aren't yet, but I assume someone is going to be willing to move the plugin code over and skin it to meet the trademark/ownership/branding requirements. > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
