Thanks for the thoughtful replies Scott. Client-side request orchestration is where I see myself headed. Your list of concerns is resonates with my concerns about the barriers on this as well.
To be thorough I've been exploring the idea from both server side and client side, and the client side does seem to offer the attractive element of avoiding network-based disruption form long http sessions. I'll have to read up more on HTTP keep-alive approaches. I'm not sure how consistent browsers are in their response to and I'd like my solution to work broadly on the obvious 3 browsers anyway. And I wonder about proxy servers and NAT behaviour - perhaps its transparent, but I'll have to dig into that a bit. Thanks though for your thoughts on a path forward. Ross. On Jun 26, 10:34 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote: > Ross, I had one more thought. > > Are most browsers capable of using persistent HTTP for XMLHttpRequests? If > so, and *assuming your main motivation is simply to be more efficient by > using a single HTTP connection* for your traffic, then I think you might be > able to implicitly exploit persistent HTTP to get what you want. If you use > a pull model rather than a push model, and have the client make its requests > frequently enough that most browsers' timeouts don't tear down the > persistent HTTP connection, and if you ensure that your responses are > suitable for use with persistent HTTP (i.e., they contain a valid > Content-Length header), then I think you may satisfy your goal. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
