incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Patch submitted, working towards API design
Date Sun, 15 Nov 2009 16:40:34 GMT
Like the idea of forcing people to use extra parameter for the call.
Means it won't be the default...


On Sun, Nov 15, 2009 at 5:36 PM, Ethan Jewett <> wrote:
> I've updated the API 2.0 design page with something very similar to
> this:
> 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.
> Ethan
> 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
>>> > 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