Manuel:
Thank you for your most detailed explanation -- I must admit most of it is over my head. However, I shall study the concept further and place your email in my "to learn" collection (I have one and it's growing faster than I can keep up).
But as of now, I can now run one php application from another, which was the request that started this thread.
tedd
----
At 3:48 AM -0500 6/19/06, Manuel Amador (Rudd-O) wrote:
>PHP tends to send output in content transfer encoding "chunked" (I think
>this is true when output buffering is on). <?php ?> blocks usually have
>their output sent in one chunk. The browser renders the chunks as they
>come, but oftentimes they delay rendering until a sensible number of
>HTML closing tags have arrived.
>
>Now, on to the real answer to your question. No, under normal
>conditions you can't have your users' browsers interact with a live PHP
>script. Web programming is Web REQUEST->PHP RESPONSE, and you must use
>support technology (like sessions, cookies or manual carryover of form
>data) to make session state persistence possible.
>
>In other words: no, if the user clicks a button, it doesn't "call a
>function or branch in an if/then control statement" immediately.
>Rather, an entirely new PHP process, totally unaware of the former one,
>is called upon to service that request.
>
>Now, while in the PHP realm, there *is* one way to have your web client
>follow the pattern "REQUEST->RESPONSE,RESPONSE,RESPONSE" ad infinitum.
>
>This is called slow loading (or Comet), and basically involves:
>
>- having the web client load a PHP script through a hidden IFRAME
>- having the PHP script *never* finish execution (unless, of course, the
>user hits Stop in his browser window), and continually send data through
>the connection (plus one ob_flush() after each chunk just to be
>politically correct). Usually, data payloads ("page updates") are to be
>carried on via JavaScript snippets, because that's about the only
>technology that allows for browser state manipulation "in vivo", I mean,
>live as the connection goes and never finishes.
>
>Given a properly architected solution, this kind of technology can
>outperform the famous AJAX, both in response times and in server load.
>Given a poorly done solution, this kind of technology can be as bad or
>dramatically worse than AJAX.
>
>Plus, you gotta remember that PHP usually has a maximum duration on
>scripts, so you need to architect around that (which isn't hard to do,
>namely you have a counter and as the counter approaches the maximum load
>time, just a few seconds earlier you send a <script>location.href
>= ...</script> to have the browser reload the IFRAME, and exit() your
>PHP script.
>
>
>
>El vie, 16-06-2006 a las 17:04 -0400, tedd escribió:
>> At 3:52 PM -0500 6/16/06, Richard Lynch wrote:
>> >On Fri, June 16, 2006 8:26 am, tedd wrote:
>> >> At 2:35 PM +0200 6/16/06, Barry wrote:
>> >>>But once output is made. You can't remove it.
>> >>>
>> >>>That isn't possible with PHP.
>> >>
>> >> I think I get it now.
>> >>
>> >> PHP does everything before the user see's anything.
>> >
>> >This is not quite 100% correct...
>> >
>> >PHP output is buffered, possibly by PHP with ob_start and friends, and
>> >then possibly by Apache, and then possibly by TCP packets and their
>> >ordered arrival (or not) and then by the browser, but...
>> >
>> >It is entirely possible to construct a trivial example proving that
>> >PHP can still be runing and finishing output while the browser has
>> >rendered the beginning of the page.
>> >
>> >You can mostly THINK of it as PHP finishing before user sees anything,
>> >as that will get you in a lot less trouble than thinking the other way
>> >around, but to be pedantic, you should be aware it's not quite that
>> >simple.
>>
>> Good explanation and point.
>>
>> How's this for the obvious -- the user doesn't see anything until php is done with it. That doesn't mean that the entire operation must be finished, but rather anything that the user see's (while and after loading) php has already finished with.
> >
>> That about right?
>>
>> tedd
>> --
>> ------------------------------------------------------------------------------------
>> http://sperling.com http://ancientstones.com http://earthstones.com
>>
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
