Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of james.strachan@gmail.com
 designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAxZHdc-=u6a7+YOO6RNWzqMfBVM558Dr3sAuHkfxH=LvVRB1A@mail.gmail.com>
References: 
 <CALvzYd8eA3G5HFLKHA2W6itJexcpZ=jQ0grHefkY4QnW6m4xUQ@mail.gmail.com>
 <1358944036289-5726055.post@n5.nabble.com>
 <CALvzYd_RZ2x-i5Fii=8AU9m14coMsRcQztyN5mJDrPc2fHQdaA@mail.gmail.com>
 <CAAxZHdc-=u6a7+YOO6RNWzqMfBVM558Dr3sAuHkfxH=LvVRB1A@mail.gmail.com>
From: James Strachan <james.strachan@gmail.com>
Date: Fri, 25 Jan 2013 09:05:52 +0000
Message-ID: 
 <CALTd4v_6SyTsPfHpXmbiZTKGYrPnxT45PRTa1uZykCMEtkYjdw@mail.gmail.com>
Subject: Re: [CAMEL-3.0] Start moving forward
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On 25 January 2013 08:07, Charles Moulliard <ch007m@gmail.com> wrote:
> +1 for the project plan and if you are interested I can play the role of
> Project Manager to coordinate all the different tasks, actions, define a
> plan and
> following
> manage it
>
> Concerning the webconsole, http://hawt.io project should be the way to go
> (or at least jolokia - http://jolokia.org/ ) even if until now the code is
> too much javascript, typescript oriented (at my opinion).

You can write hawtio plugins in anything that compiles-to-JS. So use
pure JS,  CoffeeScript, EcmaScript6-transpiler, TypeScript, GWT,
Kotlin, Ceylon, ClojureScript, ScalaJS or any of the other languages
that compile to JS:
http://altjs.org/

So take your pick; the person who creates a hawtio plugin can use
whatever language they prefer; so get cracking Charles on a new plugin
and you can use your preferred language! :)

The only real APIs a plugin needs to worry about are AngularJS (if you
want to work in the core layout rather than just be an iframe), JSON
for some pretty trivial extension points like adding new tabs and HTML
& CSS. We'll probably move to something like RequireJS for dynamic
module loading at some point; but thats pretty language agnostic
anyway.


> Nevertheless, the webconsole project for Camel should be designed as
> pluggable, REST based,
> most probably synchronized with also commands that
> we have in Karaf (to avoid to duplicate code), packaged as a WAR deployable
> in any Java container (Tomcat, TomEE, Jetty, JEE, Karaf).

That describes hawtio pretty well already. Now we've got hawtio I'm
not sure why we need another web console project?

The missing bit is reusing karaf commands easily in a web console (as
they are text console based which isn't ideal); ideally we'd be able
to introduce an 'object layer' within the commands so that they can
expose JSON objects before they are turned into text console strings -
so that a web UI can provide a richer visualisation.

e.g. check the comments on this issue - in particular try watching the
TermKit demo videos to show the kinds of things a command shell could
look like in a browser...
https://github.com/hawtio/hawtio/issues/17

Though the karaf commands are discussion for the karaf project.

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration