camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian MĂĽller <>
Subject [DISCUSS CAMEL 3.0] weekly IRC chat at 02/05/2013 7:00PM - 8:00PM CET
Date Tue, 05 Feb 2013 19:01:58 GMT
This was the today's discussion on IRC (irc:// 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
[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 ( 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 ( 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 ( 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 ( 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. ->
[19:06:50]      elakito (~elakito@ joined the channel.
[19:07:05]      olamy ( 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 ( 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 ( 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 ( left IRC.
[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 (
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>
[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@ left IRC. (Client closed
[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
[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 ( 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 ( joined the
[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 ( left IRC.
("Computer has gone to sleep.")
[19:42:07]      lhein ( joined the
[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
[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 (
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@ left IRC. (Ping timeout: 20
[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
[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



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message