esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: ESME and Akka
Date Sat, 18 Jun 2011 14:34:44 GMT
@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 <vdichev@apache.org> 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 <esjewett@gmail.com> 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 <vdichev@apache.org> 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
>

Mime
View raw message