On Jun 25, 4:56 pm, "Richard Dahl" <[EMAIL PROTECTED]> wrote:
> Generally with HTTP, you would configure your server to continue to respond
> to requests;)  Which is exactly what django does anyway.

That's my question - rather than one response to a request I'd like to
have several responses.  For example a user requests continuous
traffic information and the server replies with continuous replies of
the number of cars per second. So one reply with multiple answers,
with the TCP connection left open until the data flow reaches a
condition (e.g. fewer than  5 cars per second).

> HTTP is a connection based (TCP) protocol, but the connection is closed once
> the return has been sent.  Hence the need to store a 'session' variable in
> the server and use a cookie on the browser with a corresponding session id.
> Data does not live beyond the request.  You cannot define a variable within
> your django view or Apache process and pass it back to the client on the
> next request.

Not something I'm interested in doing - just want to send _one_
request then start receiving a couple of messages containing a few
characters every second or two.


 You can only put a variable within a session record, at which
> point it goes out of memory for all useful purposes, and then put the
> variable back into memory from the session record on the next request
> matching the session id.
>
> AFAIK (and I *think* I understand TCP/IP/HTTP fairly well) there is no way
> to have an HTTP server initiate a connection to a browser.  Browsers (HTTP
> Clients) do not listen on TCP ports for incoming requests, otherwise, they
> would be HTTP servers.

I think you're right, but I don't want to do that anyway.  :)

>
> As far as streaming (in the video sense), over http, you are just
> downloading a file, albeit usually a really big one, via HTTP and the player
> makes it play before the download is finished.  It really is though nothing
> more than a 'single' response, in the sense that once the file is done
> downloading the request is terminated.

I suppose if I could make my small messages (5, 10, 6, 8, 9...) be
readable during the stream that would be fine.  Like a big file whose
content isn't know by the server 'cause it hasn't all been created
yet.  But I'd need the browser to be able to start opening and using
the data before the 'all done' flag is raised.

>
> Now, this is a pretty simple explanation of how this works, in reality when
> you request a web page, you usually are getting more than one file (hence
> more than one request/response), as all external files (css, js, images
> etc...) referenced on a page will be requested by the browser as well. But
> the browser does the requesting.  Look at your Django console messages and
> you'll see this.
>
> It is however, possible to have a javascript function request information
> asynchronously or request a page refresh (oh the horror) at a given
> interval of time.

Yes, that is my current tack - repeated ajax requests from the
browser. It seems a little less elegant from a client server
paradigm.  I want a flow of information, so artificially constructing
the flow as a series of requests sounds do-able but more sensible
would be a single "give me a flow of info" request and a server
construct that can keep open a tcp socket that provides messages until
I'm ready to terminate.  Hence my question.

  This is how many sites implement live coverage of events,
> like Apple's WWDC. Perhaps if you explained a bit more of what you are
> trying to accomplish, someone may be able to suggest some javascript library
> or function that can do this...

As above - the cars per second message delivery.  Or perhaps think of
a continuous weather report "start giving me second-by-second
precipitation, temperature and wind-speed 3-tuples.

> hth,
> -richard

-Ross
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to