esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <>
Subject Re: Patch submitted, working towards API design
Date Thu, 05 Nov 2009 15:39:50 GMT
Hi Ethan
I also thought about XMPP, but I think it's not really HTTP based, but using
raw sockets.

Also there seems to be ways around this. Google wave seems also to use

I think it would good to have an API that can be used by rich clients as
well as browser based applications(mashups?).


On Thu, Nov 5, 2009 at 2:30 PM, Ethan Jewett <> wrote:

> Hi all,
> One of the key design goals of this new API is to use RESTful
> approaches for HTTP resources and Streaming approaches for
> Streaming/Message-queue resources. Which is to say, I'm trying to do
> exactly what Vassil says.
> So yes, I really want to do a streaming API for streams/queues, and
> I'm going to re-enable the comet-based interface in the existing API
> at the API2 endpoint just as soon as I figure out how the client
> should indicate that it wants to use Comet-based long-polling of a
> resource (which I think was what Markus was giving input on when this
> whole conversation spiraled out of control).
> However I don't plan on this being the long-term approach because I
> think that it is fundamentally flawed to stream over HTTP. This seems
> to be just about the least efficient way we can do this. My reading
> indicates that XMPP is probably better and AMQP is probably best. I'd
> still looking for points of view on this as I am by no means an
> expert.
> I'm also concerned about the approach of using the Lift comet actors
> to stream, because the implementation could (and apparently will,
> based on comments from Vassil and David) change in Lift and break the
> API. The ability to abstract the implementation details is great if
> you are building a web application where you control both the client
> (browser) and server (Pulse, for example), but we are trying to build
> an API in addition to a web interface, which (at least in my mind)
> requires a reliable interface that serves as an abstraction of the
> backend, so that every implementation change on the server doesn't
> break clients. If the server implementation of the messages API
> changes, clients are not going to change, they are just going to
> break.
> So anyway, those are my concerns. I'm on board with the goal, I'm just
> advocating for considering other approaches. And better, I'm now up to
> speed enough to write some code to try them out! :-)
> Ethan
> On Wed, Nov 4, 2009 at 1:14 PM, Vassil Dichev <> wrote:
> > OK, let's start the discussion again. For the API calls which are not
> > comet-related, ESME could benefit to apply the RESTful principles
> > which make sense.
> >
> > As for Comet, my team has rejected Yammer in the past for short
> > scrum-like meetings of remote teams because if everyone has to wait
> > what the others have to say, the meeting is prohibitively long (and it
> > takes less than 30 seconds to update one message). I don't claim that
> > everyone has this need or even that we're not trying to fit a tool
> > into a scenario it wasn't meant to do. But it sure is one of the cool
> > factors for everyone I've demoed ESME to. If we're not different than
> > the competition-, Yammer,, etc., then I'm not
> > sure we can compete just on the speed of copying features from the
> > others.
> >
> > At any rate, time will tell if Comet is a key differentiator or is
> > dragging us down. But since we have it already, why would we give it
> > up?
> >
> > I would even suggest that we have both APIs compete with each other
> > and see which one clients would choose to use.
> >
> > Vassil
> >

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