[uf-rest] AHAH and delay: "push" as "lazy pull"

[Ryan King]

On Nov 27, 2005, at 9:03 AM, Dr.Ernie Prabhakar wrote:

> On Nov 26, 2005, at 2:42 PM, Kevin Marks wrote:
>> Ernie, what was the thinking behind adding the delay to AHAH?
>
> A very good question, since I haven't done anything with it yet. :-)
>
> The most important point to note is that the *default* behavior  
> remains the same:
>>
>> It turns what was an async on demand call to one that polls at  
>> intervals, but only on success?
>
> That is, you can use the function as today as merely "async on  
> demand" if you don't specify a delay.
>
> However, my hypothesis is that you can also implement "push" as  
> "lazy pull."

I'm pretty sure I've seen this hypothesis proven already.

> That is, rather than having a separate open socket on the client,  
> you merely do a non-blocking pull that the server is smart enough  
> to defer resolving until there's new data, a la:
>
> 	http://example.com/user/1/messages?lastUpdate=20051128T1800Z
>
> The idea is that the server would hold the request until it had  
> something new to respond with.  I added the delay so that it  
> wouldn't bury the server with requests in the case where it  
> (mistakenly) responded immediately.
>
> This originally came up in the context of "pubsub" and "Jabber" --  
> two protocols that tend to think in terms of "push"; I wanted to  
> see whether there was a "clean" way to implement them in terms of  
> HTTP and, specifically, AHAH.
>
>> There are scenarios where this can make sense - ie if there are  
>> multiple clients that can update the state of a resource on the  
>> server, and you want a persistent connection open to react to this  
>> quickly.
>
> Yeah, that sort of thing.  Basically, any scenario where the client  
> wants 'instant' notification. The main advantage over polling is  
> that it requires much less use of network resources.  That said, it  
> does hold a connection on the server, which consumes server  
> resources.  On the other hand, I still suspect the overall impact  
> is less than if the server had to implement 'true' push (vs. this,  
> what, "pseudo-push").

There's one little problem with using this in browsers- most (I  
think) browsers will constantly look like its loading a page, which  
can be quite unsettling to users.


> Again, I haven't even tested the code yet to make sure it works,  
> much less done any detailed studies of its resource impact.   If  
> you're feeling brave, let me know how it works. :-)
>
> -- Ernie P.

-ryan
--
Ryan King
ryan at technorati.com