On Nov 28, 2013, at 8:42 AM, James Strachan <james.strac...@gmail.com> wrote:
> Should we back out the use of graphviz too? Do you think generating images > for camel routes should be -1'd too? No. Graphviz is a graphics library. ALL the code for taking the camel routes and feeding the information into graphiz lives in camel and is under the Camel PMC control and direction. How the graph is presented to the user is under the Camel PMC direction. Thus, it’s “OK”. In this case, all of the code for presenting the Camel UI is NOT in control of the Camel PMC. It’s not part of Camel. It’s completely under the control of an external party. That is NOT OK. If HawtIO was just a console framework (or whatever you want to call it) and all of the “Camel” value-add was a plugin or was built upon that and that code was in Camel, I’d have “less” of a concern (certain branding and links and doc things would need to be resolved as well). Basically, if it was like Spring where Spring has a core and all the camel value add stuff to spring (namespace handlers, spring integration stuff, etc…) is part of Camel, then it would be OK. So, in summary, if a user wants a nice graphics view of a Camel route, as far as the Camel project goes, there are three options: 1) Claim it’s not an issue and do nothing….. It’s not one of our “itches” for us to scratch. 2) Claim it is an issue, but outside the scope of our project and point people the third party applications page we have on the website for options that are available. 3) Expand the scope of Camel to include this, but in this case, it HAS to be controlled, managed, documented, branded, etc…. completely by the Camel PMC. How it’s presented to the user, etc… must be completely “Apache Camel”, not hawtio or what ever. Take your pick. Dan > On 28 November 2013 13:41, James Strachan <james.strac...@gmail.com> wrote: > >> On 28 November 2013 13:32, Daniel Kulp <dk...@apache.org> wrote: >> >>> >>> I’m -1 to this commit. I don’t think we should be adding a bunch of >>> targets for all the various container/platform integrations. >> >> >> If that were true I'd maybe -1 it too; but this commit looks to be about >> making it easy for Camel users to visualise & debug Camel routes in a web >> browser - from inside their existing maven camel project. i.e. its a camel >> thing; just needs a web server to host some static HTML/CSS/JS (which is >> purely an implementation detail). >> >> Though its nothing really to do with mimicking runtime platforms like >> tomcat:run / karaf:run / jetty:run. >> >> -- >> James >> ------- >> Red Hat >> >> Email: jstra...@redhat.com >> Web: http://fusesource.com >> Twitter: jstrachan, fusenews >> Blog: http://macstrac.blogspot.com/ >> >> Open Source Integration >> > > > > -- > James > ------- > Red Hat > > Email: jstra...@redhat.com > Web: http://fusesource.com > Twitter: jstrachan, fusenews > Blog: http://macstrac.blogspot.com/ > > Open Source Integration -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
