@Daniel - maybe Vassil can help you there. What exactly was your problem? D.
On Mon, Aug 24, 2009 at 10:02 PM, Daniel Koller<[email protected]> wrote: > 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 >
