esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <feeder.of.the.be...@gmail.com>
Subject Re: Patch submitted, working towards API design
Date Wed, 11 Nov 2009 00:10:45 GMT
On Fri, Nov 6, 2009 at 12:07 PM, Ethan Jewett <esjewett@gmail.com> wrote:

> 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
>
>
How about:
GET http://esme.org/api2/messages // long poll

GET http://esme.org/api2/messages?timeout=20 // 20 second timeout

So, by default, the server chooses the request timeout, but the client can
modify the timeout based on its needs.

This also makes the long polling the default, but allows you to deal with
other clients.  It's also not a binary thing, but a tuneable parameter.


> 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).


I think the messages call should return the set of available messages.  That
may be a null set.


> 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".
>

I think having a separate history call would make sense.  It's going to be
more computational expensive to walk the message list for history (no, it's
not going to bring the system to a grinding halt with our current workload,
but it's conceptually different from "give me the latest stuff in the bucket
or hang out for a while if the bucket's empty")


>
> 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
>



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

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