esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: API 2.0 update and design questions
Date Wed, 26 Aug 2009 17:51:18 GMT
Hi Vassil,
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



On Wed, Aug 26, 2009 at 12:19 PM, Vassil Dichev <> wrote:

> > @Daniel - maybe Vassil can help you there. What exactly was your problem?
> @Daniel- I realize now we intended to make the message parser
> pluggable, but then there was always something which seemed more
> important. I think this is the right time to get back to this issue.
> The problem here is that many of the higher-level parser combinators
> use common low-level combinators, i.e. email address, identifier
> characters (for usernames, pool names, etc.). In order to reuse these,
> it's a good idea to separate and document the low-level parser
> combinators we can rely on (like an API).
> @Ethan- Regarding "streaming", we already have long-polling that's
> built in Lift with the Comet actors. Using Atom is OK, but it's
> certainly serves a different purpose, since it's not real-time. For
> reverse HTTP you'll have to wait a while before we can even discuss
> it, since it's just in the specification draft phase. PubSubHubBub is
> also quite new, and I don't see what more it offers to what we already
> have with the comet actors. All in all, it's a bit confusing for me to
> see all those different protocols and technologies together- they
> serve slightly different purposes, and are in varying stages of
> maturity. So, again- what is the use case we want that we don't
> already have?
> I'll be more than happy to help with whatever I've learned about
> Scala- and Lift.
> Vassil

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