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

Dr.Ernie Prabhakar drernie at opendarwin.org
Sun Nov 27 07:03:25 PST 2005


Hi Kevin,

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

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.

> _______________________________________________
> microformats-rest mailing list
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest



More information about the microformats-rest mailing list