Hi all, please see my feedback below,
On Mon, Aug 24, 2009 at 1:52 AM, Ethan Jewett <[email protected]> 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. +1 > > 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, Daniel
