esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Koller <>
Subject Re: API 2.0 update and design questions
Date Mon, 24 Aug 2009 20:02:55 GMT
Hi all,

please see my feedback below,

On Mon, Aug 24, 2009 at 1:52 AM, Ethan Jewett <> wrote:
> In the meantime, there are open items that I think need to be resolved to
> move ahead. I'm listing them here along with my *opinion* to hopefully
> facilitate some discussion.
> 1. REST - I'm thinking of just dropping "REST" from the name of the API. It
> should still be designed with RESTful principles in mind where appropriate
> but it's probably time we move past this issue as a group and dropping the
> term from the API title might be a good step in this direction.


> 3. Streaming - I think there is a major question around how we stream the
> parts of the API that require streaming (messages specifically). Does ESME
> do this currently? My research seems to indicate that AMQP is probably the
> most performant and interoperable way to accomplish streaming (though JMS
> should be reasonable as well, if not as inter-operable in non-enterprise
> environments). I also seem to see that Lift has built-in AMQP support. Does
> ESME already support AMQP pub/sub? If so, then I think we can probably just
> document this support and call it a day. Other options include XMPP, and
> various streaming and pub/sub approaches over HTTP.

I created test-wise an actor some weeks ago, which sends out messages to an
AMQP infrastructure as a part of an action: it was somehow complicated to
insert this new Sender in the MsgParser.scala, so integration was hardcoded
and not very flexible.
--> if somebody could lend a hand with MsgParser-Integration and
parametrization, this could get part of the ESME code.

Thanks for putting these topics together,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message