Hi Kevin,
Picking up this conversation, a friend just pointed me to:
http://www.clipcode.org/messaging/http_async_notif.html
This seems a pretty reasonable breakdown of when you can (or can't)
use HTTP asynchronously. Would you agree or disagree?
One more question: if I as a client initiate an HTTP request and
wait for the response, the only way to cancel that request is to
close the entire connection -- which means that if I need out-of-band
communication, I either need a second connection, or I keep tearing
down and reestablishing communication. Right?
-- Ernie P.
On Nov 28, 2005, at 3:37 PM, Kevin Marks wrote:
However, my hypothesis is that you can also implement "push" as
"lazy pull."
I'm pretty sure I've seen this hypothesis proven already.
I know Rohit proposed it a while ago, as Roy alludes to here:
http://groups.yahoo.com/group/rest-discuss/message/5266
I'm just not (yet) sure of how generally applicable that is
The underlying 'pending http' model is widely used. In particular,
it is how DAAP (the iTunes sharing protocol) handles synchronising
playlist changes and detecting disconnects -(you need no traffic to
maintain a pending TCP connection, but you do get a teardown
message when it goes).
I also helped Greg Elin build this kind of protocol for his network
chat application over XMLHTTPRequest.
The key to doing it reliably is to use a sequence number in the
requests (not a timestamp, as that has potential skew and races),
so the server knows what you have already got. Also, you should
have exponential backoff and retry on timeouts and other dropped
connection errors.
A simple chat app using this might be an interesting bit of sample
code.
_______________________________________________
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
