esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Patch submitted, working towards API design
Date Sun, 15 Nov 2009 16:36:00 GMT
I've updated the API 2.0 design page with something very similar to

What do people think of the example/proposal on that page? It does
make the computationally expensive history request require the
addition of an extra parameter.


On Tue, Nov 10, 2009 at 7:10 PM, David Pollak
<> wrote:
> On Fri, Nov 6, 2009 at 12:07 PM, Ethan Jewett <> wrote:
>> On Thu, Nov 5, 2009 at 6:10 PM, David Pollak
>> <> 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
> How about:
> GET // long poll
> GET // 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
>> 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
> Beginning Scala
> Follow me:
> Surf the harmonics

View raw message