This was the today's discussion on IRC (irc://irc.codehaus.org/camel). Feel
free to join the next time and/or comment on the today's discussed items.
The next one is scheduled for 02/12/2013 7:00PM - 8:00PM CET. Feel free to
join and express your ideas/needs/whishes/...
02/05/2013 7:00PM - 8:00PM CET - DISCUSSING THE CAMEL 3.0 ROAD MAP
[18:59:20] <cmueller> DISCUSSING THE CAMEL 3.0 ROAD MAP is the topic
for the next hour. Feel free to join and express your
ideas/needs/whishes/...
[19:00:23] <cmueller> I had a mail conversation with Christian Ohr and
he will work on the Message History EIP/Message Store for Camel 3.0
[19:00:50] olamy (~ol...@38.55.0.93.rev.sfr.net) joined the channel.
[19:00:51] <hadrian> cool
[19:00:58] <cmueller> So went ahead and document he is the champion for
this task
[19:01:04] <hadrian> will move it off ideas to roadmap then
[19:01:26] <cmueller> yeah
[19:01:26] slewis (~sle...@c-24-34-129-30.hsd1.nh.comcast.net) left
IRC. ("Leaving")
[19:01:57] <cmueller> I didn't had time last week to move my tasks to
the road map page
[19:02:11] <cmueller> will do it in the next days
[19:02:23] <cmueller> I'm quite busy right now
[19:03:14] <cmueller> The "Unify uri/ref" and "remove the xxxRef
options" got +1 from Claus
[19:03:28] <cmueller> And als +1 from me
[19:03:49] olamy (~ol...@38.55.0.93.rev.sfr.net) left IRC. (olamy)
[19:04:04] <cmueller> I will move this also to the road map end of this
week, if nobody has an issue with this
[19:04:43] olamy (~ol...@38.55.0.93.rev.sfr.net) joined the channel.
[19:05:46] <cmueller> A new idea introduced be claus is "JDK support"
[19:06:22] <hadrian> what does that mean?
[19:06:45] <cmueller> After February 2013, Oracle will no longer post
updates of Java SE 6 to its public download sites. ->
http://www.oracle.com/technetwork/java/eol-135779.html
[19:06:50] elakito (~elakito@155.56.40.48) joined the channel.
[19:07:05] olamy (~ol...@38.55.0.93.rev.sfr.net) left IRC. (olamy)
[19:07:07] <cmueller> it means drop java 6 support
[19:07:15] <cmueller> in camel 3.0
[19:07:25] <cmueller> and require java 7
[19:07:56] <cmueller> and make sure (if possible) Camel 3.0 also runs
on Java 8
[19:08:07] slewis (~sle...@c-24-34-129-30.hsd1.nh.comcast.net) joined
the channel.
[19:08:32] <cmueller> In generall, it make sense for me
[19:09:51] <cmueller> but I don't know whether claus has some more
ideas (e.g. updating to code to Java 7 style sytax or something like this)
[19:11:40] <cmueller> will ping him on the mailing list about this...
[19:11:50] <hadrian> well, i guess we'll do some of that, but that's
hardly a topic to put on the camel-3.0 improvements idea
[19:12:21] <hadrian> for instance something i think would help in camel
[19:12:29] <hadrian> is an abstraction for a query language
[19:12:42] <hadrian> i think it goes hand in hand with the storage idea
[19:12:57] <hadrian> we talked about random access
[19:13:09] <hadrian> that is a query actually
[19:14:01] <cmueller> you mean to query endpoints?
[19:14:08] <hadrian> consumers
[19:14:20] <hadrian> you have that (kinda) with file/ftp
[19:14:25] <hadrian> if you specify fileName
[19:14:37] <hadrian> you could get it with jms and selectors
[19:14:45] gnodet (~gno...@ven14-2-82-235-193-35.fbx.proxad.net) left
IRC. (gnodet)
[19:14:55] <cmueller> Ahh, understood
[19:14:57] <hadrian> although that requires a new connection every time
[19:15:16] <hadrian> with sql and things like this is just embedded in
the endpoint url
[19:15:20] <hadrian> which sucks
[19:15:36] <hadrian> having a query abstraction communicates intent
[19:15:59] tmielke (~tmie...@p57bd626e.dip0.t-ipconnect.de) left IRC.
("Leaving.")
[19:16:05] <cmueller> understood
[19:16:07] <hadrian> to provide random access to a source of content
(file system/queues/db/etc)
[19:16:37] <hadrian> but at this point i don't have a concrete idea of
the best way to implement it
[19:16:46] <hadrian> security is a big thing
[19:16:57] <hadrian> i don't think we touched on that on the ideas page
[19:17:09] <hadrian> i'll probably put a few stories there
[19:17:57] <hadrian> but that's not to hard, i think the minimum would
be to have headers that provide hints about the identity of the requestor
[19:18:53] <cmueller> I think we should put the "query abstraction"
idea on the idea page. I'm +0 bacause I want promote some other - more
important - ideas (IMO)
[19:18:55] <hadrian> at the other end of the spectrum would be
multi-tenancy, that's a bit complicated
[19:19:08] <hadrian> cmueller: like?
[19:19:34] <cmueller> DSL
[19:19:42] <hadrian> more specifically?
[19:19:45] <cmueller> we talked about this last week
[19:19:53] <hadrian> ah, same thing?
[19:19:54] <hadrian> ok
[19:19:54] <cmueller> separation of the DSL
[19:20:02] <hadrian> well, +1 on that
[19:20:24] <cmueller> and I *GUESS* Claus has the same idea
[19:20:42] <cmueller> because he put "JDK8 Java DSL" on the page
[19:20:58] <cmueller> which means another DSL
[19:21:03] gnodet (~gno...@ven14-2-82-235-193-35.fbx.proxad.net)
joined the channel.
[19:21:04] <hadrian> i remember him opposing that when i proposed it a
few years back
[19:21:42] <cmueller> and than it make sense for me to put all the
DSL's into it's own module
[19:22:21] <cmueller> and we should "clean up" the DSL a bit
[19:22:35] <gsoto> I'll quote hadrian from last month: "remind me to
add conversational patterns on the camel 3 agenda"
[19:22:40] <cmueller> make it easier to extend
[19:22:42] <gsoto> I wonder what that means though
[19:23:41] <cmueller> Me too ;-)
[19:25:42] <hadrian> gsoto, cmueller: one sec to finish something here
[19:26:21] <cmueller> Another think hadrian mentioned last time was to
build a cleaner runtime model/stack
[19:26:21] <hadrian> ok, so now we have in-only and in-out
[19:26:48] <cmueller> and I'm still waiting for the example ;-)
[19:26:50] <hadrian> we don't have a model in which multiple messages
belong to the same 'conversation'
[19:28:06] <hadrian> e.g. you place an order online, you get a
confirmation number than you get a notification of payment, shipment, etc
[19:29:54] <hadrian>
http://www.infoq.com/interviews/gregor-hohpe-conversations
[19:29:57] <hadrian> for instance
[19:30:11] <hadrian> actually greg mentioned that at camel-one a couple
of years ago
[19:30:22] <cmueller> will watch it later
[19:30:39] <cmueller> gsoto should remind us next week again
[19:30:48] <hadrian> ok, the other question
[19:30:51] <cmueller> to talk about it
[19:31:12] <hadrian> the runtime model/stack
[19:31:36] cschneid1 (~cschneid@81.92.22.202) left IRC. (Client closed
connection)
[19:31:44] <hadrian> today the core is riddled with if (sync) { ... }
else { callback.done(); }
[19:31:47] <hadrian> or something like that
[19:32:02] <hadrian> there is no routing engine really to delegate
processing to
[19:32:35] <hadrian> that leads to deep stacks for sync calls (horrible
to debug)
[19:33:17] <hadrian> and large pools of threads for async calls
(waiting for each other)
[19:33:36] <hadrian> and the combination is even worse
[19:33:55] <hadrian> even harder to debug and still huge number of
threads
[19:34:21] <hadrian> the easy solution to this is using continuations
[19:34:34] <hadrian> and queue them
[19:35:16] <hadrian> pretty much what seda (the architecture, not the
camel component) was designed for
[19:35:47] gertv (~text...@d5152da66.static.telenet.be) left IRC.
(Ping timeout: 20 seconds)
[19:35:53] <hadrian> cmueller, gsoto: should i keep going?
[19:36:12] <cmueller> I'm folloing you
[19:36:23] gertv (~text...@d5152da66.static.telenet.be) joined the
channel.
[19:36:29] <hadrian> well, that's pretty much it :)
[19:36:53] <cmueller> I read the papaer/link you sent me
[19:37:14] <cmueller> it was verry theoretical - at least for me...
[19:38:08] <cmueller> I don't know what this means for Camel
[19:38:30] <cmueller> some code in the sandbox would be nice
[19:38:41] <cmueller> to get a better understanding...
[19:38:57] <hadrian> ok
[19:39:10] <hadrian> practically it means a correlation id
[19:40:25] <gsoto> sorry, I'm back
[19:40:44] <gsoto> I'll check the interview later (no audio right now)
[19:41:45] cibsen (~cib...@78-72-73-107-no33.tbcn.telia.com) left IRC.
("Computer has gone to sleep.")
[19:42:07] lhein (~lh...@p57ad2541.dip0.t-ipconnect.de) joined the
channel.
[19:42:09] <cmueller> Other topic - If I remember right, at ApacheCon
EU we also talked about less wrapping
[19:42:25] <hadrian> ah, interceptors and all?
[19:42:34] <hadrian> yeah, to me it's part of the same dsl story
[19:42:38] <hadrian> but yes, +1
[19:42:41] <cmueller> at present, we have multiple interceptores… yes
[19:43:27] <cmueller> some kind of discovering mechanism
[19:44:11] <cmueller> and only wrap the existing processor if
needed/required
[19:44:33] <hadrian> agree
[19:44:57] <cmueller> like to trace the messages
[19:45:15] <cmueller> I'm not sure whether this is tha same story for
JMX support
[19:49:06] <cmueller> Today I have to leave the chat at 8:00 PM
[19:49:28] <hadrian> quite busy myself
[19:49:37] boday (~bo...@99-120-99-13.lightspeed.sndgca.sbcglobal.net)
left IRC. ("Leaving.")
[19:50:12] <cmueller> I will ping some more committers/PMC to be a
champion for one of the unassigned tasks
[19:51:27] <hadrian> cool
[19:51:43] <cmueller> And be more active discussing Camel 3.0
[19:51:54] <cmueller> on the IRC or mailing lists
[19:53:08] <cmueller> to have a consensus what should be done in Camel
2.x, 3.0 and 3.x
[19:53:31] elakito (~elakito@155.56.40.48) left IRC. (Ping timeout: 20
seconds)
[19:53:52] <hadrian> cmueller: i take this as lazy consensus
[19:54:12] <hadrian> the bigger issue is to get guys to work on the
tasks
[19:54:21] <cmueller> yes, of course
[19:55:25] <cmueller> For now, I will remove the ideas which are
already implemented (as we discussed last week)
[19:55:44] <cmueller> and leave for today...
[19:55:59] <hadrian> ok, take care
[19:56:10] <cmueller> you too, have a nice evening
Best,
Christian
--
