esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Patch submitted, working towards API design
Date Thu, 05 Nov 2009 13:30:33 GMT
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 <vdichev@apache.org> 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- laconi.ca, Yammer, present.ly, 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
>

Mime
View raw message