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
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
