Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BFD13E576 for ; Tue, 5 Feb 2013 19:02:24 +0000 (UTC) Received: (qmail 95308 invoked by uid 500); 5 Feb 2013 19:02:23 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 95266 invoked by uid 500); 5 Feb 2013 19:02:23 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 95256 invoked by uid 99); 5 Feb 2013 19:02:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 19:02:23 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of christian.mueller@gmail.com designates 209.85.214.172 as permitted sender) Received: from [209.85.214.172] (HELO mail-ob0-f172.google.com) (209.85.214.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 19:02:19 +0000 Received: by mail-ob0-f172.google.com with SMTP id tb18so549613obb.17 for ; Tue, 05 Feb 2013 11:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=00n60UDIediwNPJoTycP9s97MyzMXAXvbYL9i9Rkhb4=; b=tUMS2huA2NOmB5LhfAzb3esOvQ+FQamlFY15uSI+lBjMGqH+yXUXlCPbd3eC2D3/Vv MohXGb/qln0Oy3qtfT60ICw+aiDVQWthcPxXuoE6qvGvsgfFocYG3JdMpWhS0ZCZdD8I q03DINWvz7til1zKETzGO4F3cLShPOi6XTI+jx/CkYex5l0E7d+MAdYPO+c2E/wZXQaS OzRKEBCSKCBqV6KRkjxRFq/Ajyls9O8By1QYQAGTNkavMjDilHe0YZqE409vUUteQ5K/ PLz02k4eKiF4kL35/rR8t0SCzLCVgBUt4vaPnUUeXq8El09Z91ByK/7E8rwB5fVi2HVs uTig== MIME-Version: 1.0 X-Received: by 10.60.8.199 with SMTP id t7mr19657492oea.26.1360090918340; Tue, 05 Feb 2013 11:01:58 -0800 (PST) Received: by 10.182.114.103 with HTTP; Tue, 5 Feb 2013 11:01:58 -0800 (PST) Date: Tue, 5 Feb 2013 20:01:58 +0100 Message-ID: Subject: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/05/2013 7:00PM - 8:00PM CET From: =?ISO-8859-1?Q?Christian_M=FCller?= To: dev@camel.apache.org Content-Type: multipart/alternative; boundary=e89a8ff1ce460cc6a304d4fed8e5 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8ff1ce460cc6a304d4fed8e5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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] 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] 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 (~olamy@38.55.0.93.rev.sfr.net) joined the channel. [19:00:51] cool [19:00:58] So went ahead and document he is the champion for this task [19:01:04] will move it off ideas to roadmap then [19:01:26] yeah [19:01:26] slewis (~slewis@c-24-34-129-30.hsd1.nh.comcast.net) left IRC. ("Leaving") [19:01:57] I didn't had time last week to move my tasks to the road map page [19:02:11] will do it in the next days [19:02:23] I'm quite busy right now [19:03:14] The "Unify uri/ref" and "remove the xxxRef options" got +1 from Claus [19:03:28] And als +1 from me [19:03:49] olamy (~olamy@38.55.0.93.rev.sfr.net) left IRC. (olamy) [19:04:04] I will move this also to the road map end of this week, if nobody has an issue with this [19:04:43] olamy (~olamy@38.55.0.93.rev.sfr.net) joined the channel. [19:05:46] A new idea introduced be claus is "JDK support" [19:06:22] what does that mean? [19:06:45] 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 (~olamy@38.55.0.93.rev.sfr.net) left IRC. (olamy) [19:07:07] it means drop java 6 support [19:07:15] in camel 3.0 [19:07:25] and require java 7 [19:07:56] and make sure (if possible) Camel 3.0 also runs on Java 8 [19:08:07] slewis (~slewis@c-24-34-129-30.hsd1.nh.comcast.net) joined the channel. [19:08:32] In generall, it make sense for me [19:09:51] 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] will ping him on the mailing list about this... [19:11:50] 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] for instance something i think would help in camel [19:12:29] is an abstraction for a query language [19:12:42] i think it goes hand in hand with the storage idea [19:12:57] we talked about random access [19:13:09] that is a query actually [19:14:01] you mean to query endpoints? [19:14:08] consumers [19:14:20] you have that (kinda) with file/ftp [19:14:25] if you specify fileName [19:14:37] you could get it with jms and selectors [19:14:45] gnodet (~gnodet@ven14-2-82-235-193-35.fbx.proxad.net) left IRC. (gnodet) [19:14:55] Ahh, understood [19:14:57] although that requires a new connection every time [19:15:16] with sql and things like this is just embedded in the endpoint url [19:15:20] which sucks [19:15:36] having a query abstraction communicates intent [19:15:59] tmielke (~tmielke@p57BD626E.dip0.t-ipconnect.de) left IRC. ("Leaving.") [19:16:05] understood [19:16:07] to provide random access to a source of content (file system/queues/db/etc) [19:16:37] but at this point i don't have a concrete idea of the best way to implement it [19:16:46] security is a big thing [19:16:57] i don't think we touched on that on the ideas page [19:17:09] i'll probably put a few stories there [19:17:57] 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] 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] at the other end of the spectrum would be multi-tenancy, that's a bit complicated [19:19:08] cmueller: like? [19:19:34] DSL [19:19:42] more specifically? [19:19:45] we talked about this last week [19:19:53] ah, same thing? [19:19:54] ok [19:19:54] separation of the DSL [19:20:02] well, +1 on that [19:20:24] and I *GUESS* Claus has the same idea [19:20:42] because he put "JDK8 Java DSL" on the page [19:20:58] which means another DSL [19:21:03] gnodet (~gnodet@ven14-2-82-235-193-35.fbx.proxad.net) joined the channel. [19:21:04] i remember him opposing that when i proposed it a few years back [19:21:42] and than it make sense for me to put all the DSL's into it's own module [19:22:21] and we should "clean up" the DSL a bit [19:22:35] I'll quote hadrian from last month: "remind me to add conversational patterns on the camel 3 agenda" [19:22:40] make it easier to extend [19:22:42] I wonder what that means though [19:23:41] Me too ;-) [19:25:42] gsoto, cmueller: one sec to finish something here [19:26:21] Another think hadrian mentioned last time was to build a cleaner runtime model/stack [19:26:21] ok, so now we have in-only and in-out [19:26:48] and I'm still waiting for the example ;-) [19:26:50] we don't have a model in which multiple messages belong to the same 'conversation' [19:28:06] e.g. you place an order online, you get a confirmation number than you get a notification of payment, shipment, etc [19:29:54] http://www.infoq.com/interviews/gregor-hohpe-conversations [19:29:57] for instance [19:30:11] actually greg mentioned that at camel-one a couple of years ago [19:30:22] will watch it later [19:30:39] gsoto should remind us next week again [19:30:48] ok, the other question [19:30:51] to talk about it [19:31:12] the runtime model/stack [19:31:36] cschneid1 (~cschneid@81.92.22.202) left IRC. (Client closed connection) [19:31:44] today the core is riddled with if (sync) { ... } else { callback.done(); } [19:31:47] or something like that [19:32:02] there is no routing engine really to delegate processing to [19:32:35] that leads to deep stacks for sync calls (horrible to debug) [19:33:17] and large pools of threads for async calls (waiting for each other) [19:33:36] and the combination is even worse [19:33:55] even harder to debug and still huge number of threads [19:34:21] the easy solution to this is using continuations [19:34:34] and queue them [19:35:16] pretty much what seda (the architecture, not the camel component) was designed for [19:35:47] gertv (~textual@d5152DA66.static.telenet.be) left IRC. (Ping timeout: 20 seconds) [19:35:53] cmueller, gsoto: should i keep going? [19:36:12] I'm folloing you [19:36:23] gertv (~textual@d5152DA66.static.telenet.be) joined the channel. [19:36:29] well, that's pretty much it :) [19:36:53] I read the papaer/link you sent me [19:37:14] it was verry theoretical - at least for me... [19:38:08] I don't know what this means for Camel [19:38:30] some code in the sandbox would be nice [19:38:41] to get a better understanding... [19:38:57] ok [19:39:10] practically it means a correlation id [19:40:25] sorry, I'm back [19:40:44] I'll check the interview later (no audio right now) [19:41:45] cibsen (~cibsen@78-72-73-107-no33.tbcn.telia.com) left IRC. ("Computer has gone to sleep.") [19:42:07] lhein (~lhein@p57AD2541.dip0.t-ipconnect.de) joined the channel. [19:42:09] Other topic - If I remember right, at ApacheCon EU we also talked about less wrapping [19:42:25] ah, interceptors and all? [19:42:34] yeah, to me it's part of the same dsl story [19:42:38] but yes, +1 [19:42:41] at present, we have multiple interceptores=85 yes [19:43:27] some kind of discovering mechanism [19:44:11] and only wrap the existing processor if needed/required [19:44:33] agree [19:44:57] like to trace the messages [19:45:15] I'm not sure whether this is tha same story for JMX support [19:49:06] Today I have to leave the chat at 8:00 PM [19:49:28] quite busy myself [19:49:37] boday (~boday@99-120-99-13.lightspeed.sndgca.sbcglobal.net) left IRC. ("Leaving.") [19:50:12] I will ping some more committers/PMC to be a champion for one of the unassigned tasks [19:51:27] cool [19:51:43] And be more active discussing Camel 3.0 [19:51:54] on the IRC or mailing lists [19:53:08] 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] cmueller: i take this as lazy consensus [19:54:12] the bigger issue is to get guys to work on the tasks [19:54:21] yes, of course [19:55:25] For now, I will remove the ideas which are already implemented (as we discussed last week) [19:55:44] and leave for today... [19:55:59] ok, take care [19:56:10] you too, have a nice evening Best, Christian -- --e89a8ff1ce460cc6a304d4fed8e5--