esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: ESME and Akka
Date Tue, 21 Jun 2011 11:19:41 GMT
I have some of those questions as well. We will still use our old
actions though, because they are related with matching a message or
ESME events, which camel isn't aware of.

Vassil


On Mon, Jun 20, 2011 at 11:33 AM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
> Our few ideas:
>
> * whether we just use the camel language for our actions
> (http://camel.apache.org/components.html)
> * Whether we restrict the camel components that are necessary
> * What about the old actions - what if they are duplicates to camel components
> * Do we just use akka camel integration in actions or at a deeper
> level as well.
> * There are camel components that read as well as write (camel-mail) -
> what do we with those?
>
> D.
>
> On Sun, Jun 19, 2011 at 7:20 PM, Vassil Dichev <vdichev@apache.org> wrote:
>> For those who might not remember, I've had some ideas about using the
>> akka-camel module some time ago:
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/201011.mbox/%3CAANLkTi=viyR_WyazJVaF3WrnZ-G5VsPSof0VMB4wDbak@mail.gmail.com%3E
>>
>> 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?
>>
>> Cheers,
>> Vassil
>>
>>
>> On Sat, Jun 18, 2011 at 5:34 PM, Richard Hirsch <hirsch.dick@gmail.com> 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 <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