incubator-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 Fri, 06 Nov 2009 20:07:50 GMT
On Thu, Nov 5, 2009 at 6:10 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
>
> Lift's CometActors are meant as UI components, not as HTTP API components.
> In fact Lift's CometActor changes behavior depending on the JavaScript
> library used for the given application.  But the existing HTTP APIs (the
> ones that I wrote) that support long polling do not use CometActors.  What
> they do is they register themselves as a listener on the User object, just
> as the CometActor does, and just as an AMQP or XMPP component could.  The
> CometActors are used for the UI.  Other Actors are used for APIs.  But at
> the end of the day, they're listeners that support asynchronous update
> messages.

Gotcha. I checked out the code and I see that now (that it isn't using
the front-end comet-actor). I'm going to plug the streaming interface
back into the api2/ endpoint - I think I'm going to make it use the
same URL and response format as the messages resource, with some
additional indicator to show that the client wants the long-poll
option. Here's what I'm thinking as far as reconciling the
REST/Streaming-HTTP approaches (ignore the URL pattern and the use of
a query string instead of a header for the moment):

Client makes "long-polling" request:
GET http://esme.org/api2/messages?longpoll=T

This request only returns when a new message shows up for the user. So
what if the client wants to grab the last X messages for the user (to
populate a timeline, for example)? Then (after it verifies that the
long-poll is set up), it:

GET http://esme.org/api2/messages

This way, clients that don't need or don't support long-polling
functionality don't need to use it (YQL only supports 30 seconds of
processing, for example, so not a very long poll) and clients that
don't need all the old messages in the mailbox can just tell the API
that they want to wait for new messages.

Here's an interesting question: Should the "messages" resource without
long-polling return the last X messages or should it only return new
messages (returning a 304 Not Modified response in the event that
there are no new messages since the last request). Should there be a
way to request the last X messages regardless, in case a client fails
to properly receive the response for some reason? I'm leaning towards
the "new messages only with a 304 response option".

BTW, I'm not talking about using eTags here because my understanding
is that those are primarily about cache-control, which is not really
the point with streams. Maybe they would make sense on the resource
representations we have, and I'd like to discuss how to set that up
and whether Lift supports them (I'll keep my eyes open for this).

Anyhow, that's my current thinking. Thoughts?

> Lift's API is in fact stable and where there are occasional breaking
> changes, the compiler flags the issues (e.g., moving from Scala's Actor
> implementation to Lift's Actor implementation).  In no case would the change
> of a Lift internal API make it impossible to support an existing HTTP API
> (or an existing AMQP or XMPP API for that matter.)
>
> But, more importantly, Xerox, Novell, and Four Square are among the high
> profile companies that have built and deployed customer-facing applications
> on Lift.  Breaking APIs so massively that web APIs no longer worked would
> cause these guys to come after me with a meat ax.

Yup, I see that, and I'm not worried about Lift's abstractions
breaking the API when they are used correctly. I was just under the
mistaken impression that the current API was using the
front-end-oriented LiftCometActors. Sorry about that :-(

Ethan

Mime
View raw message