esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <>
Subject Re: API 2.0 update and design questions
Date Wed, 26 Aug 2009 18:25:44 GMT
> Maybe I should have grouped questions 3 & 4 together. What I'm interested in
> are points of view on what streaming approach we should be using for the
> parts of the API that need to be streamed.
> I do think that all information in ESME should be accessible via HTTP, and I
> think long-polling is a good way to accomplish that for things like message
> queues. It's especially good since it already exists. In my understanding,
> long-polling is essentially a short-lived subscription that requires an open
> connection. I also threw out a few other options for pub/sub over HTTP, to
> fill out the field.
> My concern, and suspicion, is just that HTTP is not the right protocol to be
> using for this type of streaming of message queues. I'm thinking that a
> protocol like AMQP may be better suited. If we go with something like AMQP
> (for example), then I want to make sure that an HTTP method of access to the
> same messages (and hopefully the same queue, if possible) is still
> available.
> Thoughts?

I see, those technologies you were listing were just possible options,
and not a list of things we should implement.

Lift does offer integration with AMQP and we were discussing on the
ESME mailing list about using that. I also think there might be value
in Atom since it offers the easiest way for a client to check which
messages are new (couple of lines of Scala code). As for real-time
updates over HTTP, the way to go is to use an abstraction like the
Lift CometActor, so whenever there's a better technology than long
polling out there, the CometActor can be reimplemented in it and no
changes in ESME are necessary whatsoever. In fact, if memory serves me
right, David has mentioned that Comet would be reimplemented in
Reverse HTTP when it matures a bit.


View raw message