| Re: Output status during processing [message #179536 is a reply to message #179533] |
Mon, 05 November 2012 16:32   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
Denis McMahon wrote:
> On Sun, 04 Nov 2012 13:52:35 -0800, Scott Johnson wrote:
>> I could use AJAX to load the file and then process it in the background
>> sending status points as it goes through AJAX.
>
> Back up a step.
>
> The server can't "send" status updates to the browser using ajax in the
> normal case,
_Usual_, not normal.
> rather the browser would request "request" status updates from the server,
> usually in relation to some browser event (which might be a javascript
There is no javascript.
> timer timeout, or the user clicking a "get update" button or link).
Yes.
> Ajax,
… is a misnomer used only by people who do not know better. It does not
need to be asynchronous, it does not have to be JavaScript (or any other
ECMAScript implementation), and it often does not use XML.
> which is built on the http request / response, which is in turn
> built on a tcp/ip connection,
_HTTP_ and _TCP/IP_
> is not a technology which generally allows
_Usually_, not generally.
> the server to push unsolicited data to the browser, rather it is a
> technology that allows the browser to make requests to the server and
> receive data back without reloading the page being displayed.
>
> Specifically, when you make an http request to a server, a tcp connection
> is opened to the server.
Correct.
> The connection is usually closed after the server has sent the response.
Utter nonsense. HTTP/1.1 uses persistent TCP connections by default.
HTTP/1.1 (RFC 2616) is currently an IETF Draft Standard. It was first
issued in 1999 and is widely implemented today: HTTP/1.1 is the default
protocol version in modern Web browsers.
> Making a connection to the server is easy, because tcp/ip knows that the
> server is listening to http on port 80.
Or any other port. 80/tcp is the default port for HTTP, not the only one.
> In the other direction, there is no official port that a browser listens
> out on for a server to make a connection to it, which makes it difficult
> for the server to open a connection to the browser to just send it
> something.
An official port number is not required. A privileged application in the
browser (a browser extension) can listen for push notifications from a
remote client on an unused TCP port > 1024. Which is done.
However, it is also possible that an HTTP client keeps a listen-connection
(and therefore a local TCP port) open for a specific HTTP server, waiting
for push updates from that server through that connection. That application
model is currently called Comet, among other names.
<http://en.wikipedia.org/wiki/Comet_(programming)>
(The caveat there is that an HTTP client is supposed to limit the number of
connections to the same server or proxy, meaning that this "connection port"
of the browser's HTTP client cannot be used for accessing other resources as
Web browsers follow that recommendation in the RFCs.)
There are other approaches (like server-sent events and the HTML5 WebSocket
API) that accomplish the same. They are referred to at the bottom of that
article.
> I know it may sound like a petty distinction to make, but making the
> distinction helps you keep it clear in your mind how it all fits
> together, and in the concept of php running behind a web-server, the
> context is generally servicing and responding to requests from the
> browser, not pushing data to the browser.
If only you knew what you are talking about.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]