Like the idea of forcing people to use extra parameter for the call. Means it won't be the default...
D. On Sun, Nov 15, 2009 at 5:36 PM, Ethan Jewett <[email protected]> wrote: > I've updated the API 2.0 design page with something very similar to > this: http://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design > > 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 > <[email protected]> wrote: >> On Fri, Nov 6, 2009 at 12:07 PM, Ethan Jewett <[email protected]> wrote: >> >>> On Thu, Nov 5, 2009 at 6:10 PM, David Pollak >>> <[email protected]> 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 >> >
