esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <>
Subject Re: ESME and Akka
Date Sun, 19 Jun 2011 17:20:07 GMT
For those who might not remember, I've had some ideas about using the
akka-camel module some time ago:

It makes sense, since Camel provides solutions to various integration
scenarios, which is one of the use cases for ESME.

I've also not been in a hurry XMPP using the Lift library, because if
we use the Akka route, we will get this for free.

Let me take some time to think about how this can fit into ESME. If
there are no other major features planned for 1.4- why not?


On Sat, Jun 18, 2011 at 5:34 PM, Richard Hirsch <> wrote:
> @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
>>>> ( 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
>>>> ( This might help with
>>>> federation/clustering in the future.
>>>> 2. Akka has nice Camel integration (
>>>> Camel has a lot of endpoint components, which are conspicuously
>>>> similar in intent to our actions:
>>>> ( 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:
>> Blog:

View raw message