Log from today's GWT-charting meeting

Heiko W.Rupp hrupp at redhat.com
Fri Jun 8 15:34:10 UTC 2012


[16:00:44] <pilhuhn> #startmeeting
[16:01:08] <pilhuhn> #topic Options for GWT-charting to replace the old metric charts in RHQ
[16:01:41] <pilhuhn> Denis (kruskod), one of our two GSoC students has done some research and will now present findings
[16:02:47] <kruskod> So
[16:03:10] <kruskod> Greetings to all
[16:03:16] <jshaughn> Hi Denis
[16:03:23] <ips> hey
[16:03:30] <kruskod> I want you to imagine
[16:04:33] <kruskod> an updated version of the review JS libraries for visualization
[16:05:30] <kruskod> In which I have considered all comments and suggestions are written in the discussion on the rhq-devel
[16:05:40] <kruskod> http://kraskniga.blogspot.com/2012/06/comparison-of-javascript-data.html
[16:06:12] <kruskod> I suggest you view the matrix
[16:06:27] <pilhuhn> holy cow that table is huge
[16:06:39] <mtho11> ah excellent!
[16:06:47] <jshaughn> nice
[16:07:42] <kruskod> Yes, here are collected 280 features 20 of the best JS libraries
[16:09:06] <kruskod> I was even banned from stackoverflow, when I assessed the health of the projects)
[16:09:25] <asantos> way to take one for the team kruskod :)
[16:09:32] <jsanda> is it worth considering ones that do not already have support for GWT?
[16:09:34] <ccrouch> i hate it when people do a half-assed job
[16:09:36] <jkremser> lol
[16:09:54] <asantos> yes jsanda, I believe it is
[16:09:54] <pilhuhn> So I see 8 times GWT support.
[16:10:05] <ccrouch> jsanda: can you define "support for GWT"
[16:10:41] <pilhuhn> One thing I would love to see (but this is lower prio I guess) is to be able to re-use the actual charting code from the internal charts and via the REST api
[16:11:06] <jsanda> ccrouch: i'm referring specifically to the GWT support column
[16:11:15] <pilhuhn> Fetching the data may be different, but once the data is fetched into the framework the painting code could be the same
[16:11:27] <mtho11> I think the more general question is: what features can we not do without? That would eliminate some js libs from the start.
[16:11:33] <kruskod> On Web sites, projects do not write about RestAPI
[16:11:33] <asantos> + ∞  pilhuhn
[16:11:34] <ccrouch> right, i would like to be able to recommend a charting solution to our customers/users that they could use in their apps, which might not be GWT based
[16:11:38] <jkremser> do we need to incorporate custom graphics?
[16:11:44] <ccrouch> pilhuhn: +1
[16:11:57] <ccrouch> asantos: and his fancy infinity key
[16:12:18] <ccrouch> mtho11: +1
[16:12:20] <asantos> t(ツ)_/¯
[16:12:24] <ccrouch> focus on features
[16:13:17] <pilhuhn> mtho11 can we get smartgwt into a state where within a "portlet" a library can just manipulate dom elements?
[16:13:44] <ccrouch> i'm also wary of any library that somes with its own license
[16:13:54] <ccrouch> as opposed to MIT/apache etc
[16:14:04] <mtho11> pilhuhn: Hmmm there is GQuery...
[16:14:34] <ccrouch> we'll need to run it by legal probably :-(
[16:14:38] <jkremser> via JS native interface it is plausible too
[16:14:57] <mtho11> yes, JSNI wrappers around JS would be easy
[16:15:23] <asantos> ccrouch - a 'non-standard' license seems to be a show-stopper
[16:15:35] <pilhuhn> e.g. in D3 the library itself does not paint, but the user code does. And if we could get the inside of a "GWT portlet" to just give us its DOM, we could graphs via standard html div elements + css . Or via SVG, which browsers support theses days
[16:15:43] <jshaughn> re: licenses, we can't use anything that has a pay for commercial, or even a linkback requirement I would think.
[16:16:39] <kruskod> I want to note that libraries that do not have the GWT wrapper (like Cubism.js) can also be accessed via JSNI
[16:17:45] <jkremser> ..but it is pain, I was doing the same with Dojo in the past and it was too much of effort
[16:17:53] <jshaughn> kruskod: we already use sparklines, I'm not sure what we do for that
[16:17:58] <asantos> kruskod - is there anything in your chart that has a *requirement* on gwt or smart gwt?
[16:18:03] <mtho11> kruskod: so you think the level of effort to convert a standard would be very feasible (via JSNI)?
[16:18:04] <asantos> e.g. google chart tools?
[16:19:59] <kruskod> I think we must proceed from the opportunities offered by a library. If they are satisfied - quite feasibly implement the transfer of data via JSNI
[16:20:56] <ccrouch> so here is an editable list of the libraries, if people want to keep track of particular comments they have about them
[16:20:57] <ccrouch> http://piratepad.net/I2f1x9JpXE
[16:21:20] <ccrouch> e.g. non-standard licence
[16:21:42] <ccrouch> i'm almost ready to start crossing those ones off the list right now
[16:21:47] <ccrouch> anyone else have thoughts?
[16:22:20] <kruskod> google chart tools is not suited to us, because the data can be sent for rendering on a network. And not all companies will want to publish their data
[16:23:19] <jshaughn> I think that's true
[16:23:31] <mazz> I just commented on that
[16:23:34] <mazz> we can't use google charting
[16:23:44] <mazz> the data is sent to google servers to be rendered there, IIRC
[16:23:50] <mazz> I remember playing with that a couple years ago
[16:23:59] <mtho11> [All] is html5 canvas a killer feature that we can't do without [just trying to narrow the list]?
[16:24:00] <mazz> unless they changed its implementation, which I don't think they diid
[16:24:22] <ccrouch> mtho11: whats the alternative?
[16:24:40] <kruskod> yes, i think, that HTML5 is killer feature
[16:24:48] <ccrouch> (9:18:04 AM) asantos: kruskod - is there anything in your chart that has a *requirement* on gwt or smart gwt?
[16:24:56] <ccrouch> i think thats a good question ^
[16:25:10] <ccrouch> i would tend to be -1 on such libraries
[16:25:18] <jshaughn> I don't think there is
[16:25:32] <jshaughn> certainly not smartgwt
[16:25:34] <jkremser> me neither
[16:25:41] <jshaughn> and I'm pretty sure not gwt
[16:26:11] <kruskod> html5 automatically gives the support for mobile devices based on iOs and Android
[16:26:39] <pilhuhn> not sure if that is relevant for the UI, as the outer stuff that GWT creates is so huge
[16:27:23] <kruskod> Sorry, can clarify the issue:
[16:27:26] <kruskod> (9:18:04 AM) asantos: kruskod - is there anything in your chart that has a *requirement* on gwt or smart gwt?
[16:27:47] <jkremser> there are some candidates with size up to ~3megs if it is not modular architecture it is unusable imho
[16:28:01] <ccrouch> (9:26:17 AM) kruskod: html5 automatically gives the support for mobile devices based on iOs and Android
[16:28:01] <ccrouch> but this would be helpful from a rest api perspective, or customized UIs
[16:29:29] <pilhuhn> ccrouch Yes, the latter is the advantage that I see
[16:30:11] <kruskod> I'll have to choose your attention on Two library: D3 and Flot
[16:30:49] <pilhuhn> to paraphrase ghinkle : "You had me at D3 " :)
[16:31:04] <kruskod> Both have a good license and html5 support
[16:31:29] <mtho11> do we know that either will produce all the kinds of graphs we currently use?
[16:31:30] <kruskod> http://d3js.org/
[16:32:22] <pilhuhn> mtho11 With D3 you can create everything. Have a look at localhost:7080/rest/ - and the examples there
[16:32:44] <kruskod> The list of groups supported by the graphs given in the second column
[16:32:50] <mazz> flot has gwt support and is mobile friendly (so the chart says), which is things D3 doesn't have
[16:33:14] <pilhuhn> mazz html 1.0 is also mobile friendly
[16:33:22] <kruskod> Both of the above libraries have excellent "health"
[16:33:27] <mazz> I'm just going by the chart :)
[16:34:05] <jshaughn> Can we list what chart types we have currently?  The most intense chart is, I think, the timeline view. Which is an interactive time series with event overlays, right?  We also use line charts with overlayed lines for data comparison
[16:34:19] <ips> any other disadvantages of d3 besides that we'd have to wrap it in jsni ?
[16:34:19] <jkremser> https://github.com/flot/flot/graphs/commit-activity  (excellent?)
[16:34:37] <mazz> http://code.google.com/p/flot/wiki/Plugins
[16:34:46] <mazz> that shows the different flot plugins and their charts
[16:34:46] <pilhuhn> jshaughn That itmeline is the simile widgets originally from MIT - that is already a JS library
[16:35:12] <pilhuhn> we only feed timeline.js via some JSP pages. But you can feed through whatever you want (e.g. rest api :-)
[16:35:23] <kruskod> Flot looks simpler, but  it has a special project for the GWT Flot - gflot
[16:35:28] <mtho11> i'm curious since d3.js is so popular why it doesn't have a gwt wrapper already. Is there something about the programming style that makes it difficult to be wrapped via JSNI?
[16:35:37] <mazz> right - in fact, that timeline really just gets JSON data output from the .jsp
[16:35:49] <mazz> as long as it has some endpoint that it can get json data, wer're good
[16:36:23] <pilhuhn> mtho11 In d3, the library gives you support to e.g. calculate where things should go, but the user code sets the actual dots / lines.
[16:36:25] <kruskod> The table also presents D3 plugins: Rickshaw and Cubism
[16:36:30] <pilhuhn> So I see this as orthogonal
[16:36:35] <ccrouch> I've rearranged http://piratepad.net/I2f1x9JpXE to highlight the top candidates
[16:37:03] <ccrouch> (9:34:12 AM) jshaughn: Can we list what chart types we have currently?  The most intense chart is, I think, the timeline view.
[16:37:04] <ccrouch> +1
[16:37:13] <rhq-bot> mtho11 - it sounds like integrating d3 w/ gwt is doable -http://stackoverflow.com/questions/9814197/using-d3-script-in-gwt-application-using-jsni
[16:37:20] <ccrouch> but do you think we could really replace that one jshaughn
[16:37:28] <ccrouch> its it super funky
[16:37:39] <pilhuhn> Do we need to replace it ?
[16:37:44] <ccrouch> with its time line based view
[16:37:52] <pilhuhn> I think the metric charts are the ones we should concentrate on
[16:38:10] <ccrouch> i think that makes sense pilhuhn
[16:38:14] <jshaughn> if we don't need to replace it then no
[16:38:33] <pilhuhn> like drawing charts for 1 metric or many -- luckily in JS charting you usually paint all (if you want multiple) and have them show/hide via css magic
[16:39:10] <ips> the timeline is another js lib, so we should be able to wrap that in jsni too, then it could be moved from portal-war to coregui
[16:39:21] <asantos> cubism is a nice timeline that works on d3
[16:39:30] <asantos> *works with*
[16:39:36] <pilhuhn> sits on top
[16:39:43] <asantos> that too
[16:39:58] <kruskod> Cubism used 1 pixel for one metric
[16:40:20] <pilhuhn> and cubism is also (co) written by Mike Bostock, who is the main author of D3
[16:40:50] <asantos> kruskod, help me understand why that is important?
[16:41:08] <asantos> is it good or bad :)
[16:41:25] <asantos> oh, wait, just saw it
[16:41:36] <asantos> " lets Cubism scale easily to hundreds of metrics updating every ten seconds!"
[16:41:54] <kruskod> This will allow the beautiful display large amounts of data on small plots
[16:42:24] <kruskod> This is a plus
[16:43:59] <asantos> definitely
[16:44:20] <mtho11> it feels like we are dialing in around d3 and its plug-ins...
[16:44:40] <ccrouch> mtho11: "So you can get a lot of ideas from the protovisGWT wrapper and maybe you can also even implement a GWT wrapper for d3.js."
[16:44:51] <mtho11> right
[16:44:56] <ccrouch> that doesn't sound great :-/
[16:45:07] <ccrouch> in terms of requiring us to do a bunch of work
[16:45:19] <kruskod> Look also at Flot
[16:46:11] <jshaughn> in our original investigation ghinkle liked dygraphs, especially for its range charts, kruskod, any comment?
[16:47:24] <mtho11> maybe we can have kruskod prototype a couple charts via gwt using  X and Y?  Then we can see what kind of issues there really are?
[16:47:28] <rhq-bot> re the timeline: http://code.google.com/p/gwtsimiletimeline/ - hasn't been updated since 2008 but at least provides a starting point for integrating the timeline w/ gwt
[16:47:32] <kruskod> dygraphs is on tric pony
[16:48:30] <kruskod> It can only draw time series
[16:48:56] <jshaughn> ok
[16:49:30] <jsanda> maybe this is a dumb question but aren't we primarily if not entirely interested in time series?
[16:50:17] <pilhuhn> jsanda For the metric charts I guess so
[16:50:19] <asantos> jsanda - I think that's only the case if you simply want to replace what we have now
[16:50:37] <pilhuhn> asantos yep
[16:51:02] <pilhuhn> I can also imagine that we do more interesting stuff in the future like graphing resource relations
[16:51:27] <jsanda> pilhuhn: good point/example
[16:52:17] <pilhuhn> But then … replacing what we have and improving it by e.g. allowing the user to define virtual graphs   f(t) = metric_a(t) + metric_b(t) would be already quite good
[16:54:37] <mtho11> kruskod: I'm curious why Rickshaw uses d3 and yet doesn't support html5 canvas?
[16:55:45] <kruskod> From site: It's all based on d3 underneath, so graphs are drawn with standard SVG and styled with CSS.
[16:55:59] <kruskod> http://code.shutterstock.com/rickshaw/
[16:56:29] <kruskod> Nothing is said about using the tag Canvas
[16:57:27] <asantos> I hadn't seen rickshaw - that's purty
[16:57:38] <kruskod> I have not received an explanation from developers Ritskshaц
[16:57:48] <jkremser> btw. do you think IE8 is ready for HTML5 features / SVG? Do we have to support it?
[16:58:23] <ccrouch> http://forums.smartclient.com/archive/index.php/t-19035.html
[16:59:13] <ccrouch> jkremser: VML instead?
[16:59:24] <ips> rickshaw looks nice to me
[16:59:51] <ips> It looks to be a wrapper around D3 that allows you to create basic time  series graphs in a declarative way, rather than writing code. I kind of  like D3's philosophy of requiring coding but making that coding simple  and expressive, but I suspect there's a lot of people building websites  who find it too complicated. Maybe something like this could help them.  Also, it's awesome to see libraries built on top of D3.
[17:00:15] <jkremser> ccrouch, I don't know VML
[17:00:17] <kruskod> Maybe he has the support of HTML5 - i need to watch the source
[17:00:20] <ips> the higher level api may be easier to use as well as easier to wrap in jsno
[17:00:23] <ips> jsni
[17:00:45] <ips> and it sounds like you can still use D3 directly if needed
[17:00:50] <pilhuhn> ips rickshaw would at least to also use "raw d3"
[17:00:53] <pilhuhn> +1
[17:01:55] <ccrouch> (10:00:51 AM) ips: and it sounds like you can still use D3 directly if needed
[17:02:03] <ccrouch> so no jsni wrapper required?
[17:02:45] <ccrouch> integrating with gwt is one thing, but we're obviously integrating with smartgwt too, which never simplifies anything :-/
[17:03:23] <ccrouch> anyone care to comment on my link from above
[17:03:23] <ccrouch> http://forums.smartclient.com/archive/index.php/t-19035.html
[17:03:23] <ccrouch> where they isomorphic guys say just use smartgwt rather than D3
[17:03:23] <kruskod> Instead of GWT wrapper using JSNI
[17:03:50] <jkremser> ccrouch, yep, events might be the issue as Mike was writing in email. Do we need a lot of interaction between the graph and user or will they be more static / read only?
[17:04:06] <mazz> ccrouch: isn't that them saying "don't use that freeware stuff - pay us and use our stuff instead"
[17:04:18] <pilhuhn> jkremser We should take advantage of e.g. hovering to show the exact value
[17:04:26] <asantos> it's apparently part of the lgpl release mazz
[17:04:36] <pilhuhn> Or to show/hide individual graphs on a multi-grap display
[17:04:36] <mazz> really?
[17:04:37] <asantos> which I was surprised to see - don't they charge for charts?
[17:04:50] <mazz> yeah, I thought that was part of their for-fee stuff
[17:05:07] <kruskod> mazz +1
[17:05:22] <ccrouch> " look at the Drawing module (com.smartgwt.widgets.drawing). It's free (part of SmartGWT LGPL) "
[17:05:38] <jshaughn> Their stuff is I think requiring a fusion charts license and so it has to be a pay option
[17:06:30] <jkremser> hoovering can be done completely in the JS library, so there is no need for interaction with (S)GWT
[17:06:48] <asantos> ccrouch - maybe I'm missing something, but com.smartgwt.widgets.drawing is pretty low-level
[17:06:49] <jkremser> on "event level"
[17:07:09] <ips> Drawing module is free, but is not to be confused with the Charting module (eg: http://www.smartclient.com/smartgwtee/showcase/#simpleChart ), which is not
[17:07:13] <mtho11> asantos: exactly what i was thinking
[17:07:14] <pilhuhn> jkremser yes -- that is an event for me :)
[17:07:31] <jshaughn> drawing module is vector graphics
[17:07:38] <jshaughn> lines, shapes, etc
[17:07:41] <ccrouch> (10:07:15 AM) ips: Drawing module is free, but is not to be confused with the Charting module
[17:07:43] <ccrouch> ah ha
[17:08:01] <kruskod> Free can only draw squares and circles
[17:08:03] <asantos> besides ccrouch, that's dependent upon smartgwt :)
[17:08:10] <mtho11> they give you the tools to create your own graphing modules (if you have the budget)
[17:08:10] <mazz> so with the Drawing module we can build, like, Etch-a-Sketch
[17:08:12] <mazz> :}
[17:08:43] <ips> yeah, we can write d3 ourselves from scratch !
[17:09:00] <ccrouch> "feel free to build a lovely wood cabin with our tools, here is small hacksaw and the forest is over there. Knock yourself out"
[17:09:11] <asantos> haha ccrouch
[17:09:15] <jkremser> and with free version we can build a snowman (circles are for free :])
[17:09:16] <mtho11> great project for kruskod :)
[17:09:22] <asantos> oh wait your only talking about the graphs :)
[17:09:23] <kruskod> =)
[17:09:50] <ccrouch> ok, back to reality :-)
[17:09:53] <lkrejci> pilhuhn: so you said d3 can "compute" the graph for you, you just then need to somehow draw it... so d3 + smartgwt drawing could be conveivable?
[17:10:08] <lkrejci> conceivable
[17:10:31] <pilhuhn> lkrejci wouldn't that need calls into the smartgwt Java code?
[17:10:40] <lkrejci> i have no idea
[17:11:18] <lkrejci> but if we are going d3 way, we'd need some jsni layer anyway wouldn't we?
[17:11:35] <mtho11> yes
[17:12:04] <ccrouch> so i've rejigged http://piratepad.net/I2f1x9JpXE
[17:12:16] <ccrouch> it seems to be breaking out into 2 or 3 camps
[17:12:19] <ccrouch> d3 based
[17:12:20] <pilhuhn> lkrejci have a look at http://localhost:7080/rest/stacked3.html -- which is modules/enterprise/gui/rest-war/src/main/webapp/stacked3.html  for an example
[17:12:23] <ccrouch> jquery based
[17:12:32] <ccrouch> dygraphs
[17:13:11] <pilhuhn> lkrejci line 72 creates a <div> for each bar and then on the next lines adds some attributes
[17:13:57] <pilhuhn> d3 is really about dom manipulation -- and there should be some sort of DOM inside a "portlet" ?
[17:14:53] <ips> pilhuhn: you can always add raw html to gwt using an HTMLFlow
[17:14:57] <ccrouch> so i need to get on a call real soon
[17:14:57] <ccrouch> can we decide on next steps?
[17:15:07] <mtho11> right, and our tools for manipulating that dom would be JSNI or jquery via (http://code.google.com/p/gwtquery/wiki/GettingStarted)
[17:15:17] <ccrouch> its starting to feel like we need more analysis on the leading candidates?
[17:15:28] <pilhuhn> ips, then D3 is it for me :)
[17:15:31] <ips> i think there's also a way to get at the dom elements within arbitrary smartgwt widgets, though hopefully we don't have to resort to that
[17:15:58] <asantos> ccrouch - why does no html5 warrant a +0?
[17:16:09] <ccrouch> i got think we need to do some actual testing of the integration
[17:16:17] <ccrouch> asantos: becuase its not confirmed, no html
[17:16:17] <ips> i vote for Rickshaw, and D3 if Rickshaw doesn't work out for some reason
[17:16:31] <jsanda> +1 to some testing
[17:16:31] <pilhuhn> Ok, so I think next steps could be to find out if we can draw on such a HTMLFlow with D3 or other libraries
[17:16:42] <jsanda> testing/prototyping
[17:17:04] <pilhuhn> #action Denis to try to get d3 to draw on a HTMLFlow within SmartGWT -- in a tiny sample project
[17:17:11] <pilhuhn> kruskod ^^
[17:17:24] <asantos> sorry ccrouch, why is *html5* important?
[17:17:54] <kruskod> How long I wait for this)
[17:18:20] <pilhuhn> for what, kruskod  ?
[17:18:30] <ccrouch> asantos: I was tring to get to the bottom of that earlier
[17:18:42] <kruskod> ""Denis to try to get d3 to draw on a HTMLFlow within SmartGWT -- in a tiny sample project""
[17:19:15] <pilhuhn> kruskod no waiting. I think if you can draw with d3, we can do with any library
[17:19:42] <ccrouch> (9:24:06 AM) mtho11: [All] is html5 canvas a killer feature that we can't do without [just trying to narrow the list]?
[17:19:42] <ccrouch> (9:24:29 AM) ccrouch: mtho11: whats the alternative?
[17:19:42] <ccrouch> (9:24:46 AM) kruskod: yes, i think, that HTML5 is killer feature
[17:19:42] <ccrouch> (9:26:17 AM) kruskod: html5 automatically gives the support for mobile devices based on iOs and Android
[17:19:46] <ccrouch> asantos: ^
[17:19:58] <ccrouch> kruskod: something jkremser mentioned
[17:20:01] <ccrouch> ie8 support
[17:20:13] <ccrouch> i think thats going to be required
[17:20:20] <pilhuhn> gflot even pretends to have IE6+ support
[17:21:09] <kruskod> Yes, Gflot is jar, which natively supports GWT
[17:21:48] <asantos> ccrouch, kruskod - but lack of html5 doesn't mean no support for mobile
[17:22:24] <ccrouch> kruskod: the key thing for me is what extra boilerplate we will need to write to support d3, whether its a little/medium/huge amount
[17:22:35] <ccrouch> asantos: => easier mobile support?
[17:22:50] <mtho11> html5 is important because it is actively being developed in the new browsers (for future growth and mobile certainly). Kind of compare bit mapped graphics to vector graphics.
[17:22:56] <jkremser> well, it is going to be ok in a few months I think, but If we need now 100% support for IE8 then HTML5 may be the problem
[17:23:21] <kruskod> You can trace the trend to stackoverflow, that libraries do not have support for HTML5 is slowly dying
[17:23:55] <asantos> I understand the importance of html5 in the bigger picture, just trying to figure it out for the short term
[17:24:44] <kruskod> As the number of new topics for the last month
[17:25:19] <mtho11> certainly d3 has fallback support for older versions of IE correct?
[17:25:39] <jkremser> http://en.wikipedia.org/wiki/Canvas_element#Support
[17:25:42] <pilhuhn> mtho11 see my example from above
[17:26:11] <asantos> ccrouch - fwiw I can live with crippled ie8 support
[17:26:23] <asantos> as long as ie9/10 are not
[17:26:29] <kruskod> For IE 6 - 8, it relies on Google's excanvas library.
[17:26:33] <ccrouch> (10:17:11 AM) pilhuhn: #action Denis to try to get d3 to draw on a HTMLFlow within SmartGWT -- in a tiny sample project
[17:26:33] <ccrouch> i would say -1 on tiny sample project
[17:26:33] <ccrouch> lets get try it on some page/new page in RHQ
[17:27:11] <jkremser> "I can live with crippled ie8 support" +1 :)
[17:27:12] <ccrouch> asantos: ok, but i'd like to know what our browser support will look like going in
[17:27:13] <asantos> kruskod IE 6 & 7 are dead to us. Unfortunately IE 8 is not dead yet
[17:27:31] <mazz> "its getting better!"
[17:27:35] <asantos> it's like the monty-python movie. everyone keeps trying to dump it into the cart
[17:27:38] <asantos> exactly mazz
[17:27:42] <mazz> :)
[17:27:43] <asantos> life of brian?
[17:27:45] <kruskod> pilhuhn: ok
[17:27:52] <mazz> holy grail
[17:27:54] <asantos> ah
[17:28:15] <mazz> "bring out your dead!"... "I'm not dead yet!... I'm getting better!" (bonk).." there, now he's dead"
[17:29:07] <ccrouch> kruskod: awesome review
[17:29:55] <kruskod> ccrouch: Thank you
[17:30:11] <pilhuhn> kruskod so have you seen ccrouch saying about directly trying in RHQ ?
[17:30:16] <mazz> http://www.youtube.com/watch?v=dGFXGwHsD_A#t=49s
[17:30:23] <pilhuhn> So that is the next step now
[17:30:26] <mazz> "I feeeeel HAPPYYY"
[17:30:30] <pilhuhn> Thanks to everyone
[17:30:33] <mazz> now, see what you did?
[17:30:37] <pilhuhn> #endmeeting


-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer:  Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera



More information about the rhq-devel mailing list