Return-Path: X-Original-To: apmail-esme-dev-archive@www.apache.org Delivered-To: apmail-esme-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 1C80D6B99 for ; Sat, 18 Jun 2011 14:35:11 +0000 (UTC) Received: (qmail 85274 invoked by uid 500); 18 Jun 2011 14:35:11 -0000 Delivered-To: apmail-esme-dev-archive@esme.apache.org Received: (qmail 85218 invoked by uid 500); 18 Jun 2011 14:35:10 -0000 Mailing-List: contact dev-help@esme.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@esme.apache.org Delivered-To: mailing list dev@esme.apache.org Received: (qmail 85210 invoked by uid 500); 18 Jun 2011 14:35:10 -0000 Delivered-To: apmail-incubator-esme-dev@incubator.apache.org Received: (qmail 85207 invoked by uid 99); 18 Jun 2011 14:35:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Jun 2011 14:35:10 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hirsch.dick@gmail.com designates 209.85.161.47 as permitted sender) Received: from [209.85.161.47] (HELO mail-fx0-f47.google.com) (209.85.161.47) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Jun 2011 14:35:05 +0000 Received: by fxm19 with SMTP id 19so2565056fxm.6 for ; Sat, 18 Jun 2011 07:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qOTpEFTrv9BjuN5e1ogvrZ/fXkzHEtJd3AVZ+Lu0Cow=; b=fJJ++07piQs7Mcse3BvJNjE5ZgJnKjTBVDT7r0bQigpd81qi/wIjtbfnIX+LYYi4Cn O1CfZb+Uml/nPxp9/nNfqxvnAIK9RDBdYFcOaWtctijhpuOVi7VD24WjDeG+xA2pdwyW p0TelK3d1RnBlnarm9Cid34J0GSDbpWhkxXFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rXpEWCFQoAf6iwlf/xmEqks/1S0FZU8L/SAXiaq88jWs71sjOgciVNBX4UtLK5iDzR nBpIcHgiJ2jtIzg7RVWxr6Nkr3U56x0xXG2nZFXYRmnzc6Z46eAdDsTA3sIKnZUcW/f+ PaxDRcnHqYKK+WJoW0dwienCH59thNq0lghSI= MIME-Version: 1.0 Received: by 10.223.160.131 with SMTP id n3mr1773730fax.111.1308407684416; Sat, 18 Jun 2011 07:34:44 -0700 (PDT) Received: by 10.223.96.203 with HTTP; Sat, 18 Jun 2011 07:34:44 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Jun 2011 16:34:44 +0200 Message-ID: Subject: Re: ESME and Akka From: Richard Hirsch To: esme-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 @vassil - I just saw your tweet about camel, akka and esme. What about planning that feature for the 1.4 release? I've already pinged Vladimir about it as well. What about splitting the task between you two? We will be hopefully be finished with the 1.3 release soon and then we can start on the 1.4 D. On Mon, Nov 8, 2010 at 4:59 PM, Vassil Dichev wrote: > The question is actually very valid, since sending messages is only > part of the problem- the message handler needs to be implemented as > well as support for linking, etc. > > But yes, they're very compatible, since David Pollak and Jonas Boner > worked together on a common actor interface, so it should be purely > mechanical replacement (haven't tried to dig into details however) > > > On Mon, Nov 8, 2010 at 5:42 PM, Ethan Jewett wrote: >> +1 >> >> Question: Are Lift actors and Akka actors compatible? So, for example, could >> we do this incrementally, replacing the Distributor with Akka actors first >> and then working out to the other actors? >> >> Ethan >> >> On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev wrote: >> >>> Folks, >>> >>> For a while I've been thinking about integrating Akka >>> (http://akkasource.org/) into ESME. Akka is a library for concurrency, >>> fault-tolerance and remoting and actors are one of its most important >>> components. The advantages of using Akka are: >>> >>> 1. Easy remoting- it's trivial to make an actor remote >>> (http://doc.akkasource.org/remote-actors-java). This might help with >>> federation/clustering in the future. >>> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel). >>> Camel has a lot of endpoint components, which are conspicuously >>> similar in intent to our actions: >>> (http://camel.apache.org/components.html). If we replace our actions >>> with Camel components, we will have a ready DSL for dozens of actions >>> at little extra effort. For instance, XMPP support is supposed to >>> become trivial (at least at first glance). >>> >>> The upside is that it should be fairly ealy to replace Lift actors >>> with Akka actors where (and if) needed. The downside is having another >>> library dependency- but we also won't need to implement and maintain >>> all the different action types. >>> >>> What do you think? I will let you know how this idea matures and how >>> my research goes. >>> Vassil >>> >> > > > > -- > Twitter: http://twitter.com/vdichev > Blog: http://speaking-my-language.blogspot.com >