Re: [Proto-Scripty] Re: Progressive update messages from single request
Joe.
Certainly in winblows the output buffering may not work due to the modules
and the way memory is managed in winblows differs to *nix.
I have tested it on CentOs, Debian, BSD, HP UNIX,Solaris and it works fine
but not tested it on Wamp...
Alex Mcauley
http://www.thevacancymarket.com
- Original Message -
From: "joe t."
To: "Prototype & script.aculo.us"
Sent: Sunday, December 13, 2009 12:49 AM
Subject: [Proto-Scripty] Re: Progressive update messages from single request
My crude-imentary tests are on my Win7 laptop using Wamp, which means
mod_deflate. Work server is Cent, but i don't know whether it's got
any compression modules enabled (i've tried with the admin, he
slacks).
-joe t.
On Dec 12, 4:17 am, "Alex McAuley"
wrote:
> Joe.
>
> Are you using ob_gz_handler(); or mod_defalte / mod_gzip ?
>
> Also is it a winblows or *nix server
>
> Alex Mcauleyhttp://www.thevacancymarket.com
>
> - Original Message -
> From: "joe t."
> To: "Prototype & script.aculo.us"
>
> Sent: Saturday, December 12, 2009 2:24 AM
> Subject: [Proto-Scripty] Re: Progressive update messages from single
> request
>
> Alex,
> Thanks for the sample. i must be missing a piece somewhere
> though...http://pastie.org/739926
>
> From that single Ajax.Request, the client delays, and after the PHP is
> done running, i get the complete output in one block. What i'd
> anticipated was that in each loop, the flush() would somehow send that
> output to the client where it could be used, then the next loop's
> flush would send another output to the client...
>
> If i'm understanding it, Ajax is a single-request-single-response. i
> can't output the current step a process is in as it happens. i can
> accumulate them, as your model shows, and dump that out as a log, of
> sorts. But in order to monitor progress of one request's processing on
> the server, a series of follow-ups have to get feedback which the
> original is providing on the side (as T.J. recommended).
>
> Unless i'm missing something, which would be great if you could help
> me fill that in. :)
> -joe t.
>
> On Dec 11, 3:29 am, "Alex McAuley"
> wrote:
> > in your ajax request file
>
> > > ini_set('output_buffering',0); // make sure the output_buffering
> > directive
> > is not set high
> > ob_start(); // before anything is echoed to the screen
>
> > for($i=0;$i<10;$i++)
> > {
> > echo('Printing Line '.$i.'');
> > ob_flush();
> > flush();
>
> > sleep(1); // sleep for one second
>
> > }
>
> > ?>
> > this will output a line every second for 10 seconds
>
> > Hope this helps
>
> > P.S if you use ob_gz_handler this may not work (untested using it)
>
> > Alex Mcauleyhttp://www.thevacancymarket.com
>
> > - Original Message -
> > From: "joe t."
> > To: "Prototype & script.aculo.us"
> >
> > Sent: Friday, December 11, 2009 1:00 AM
> > Subject: [Proto-Scripty] Re: Progressive update messages from single
> > request
>
> > david:
> > The buffer/flush path seems to be where this solution is heading.
> > Don't ask me why, but iframes rub me the wrong way. With the evolving
> > needs for more streamlined connections, iframes feel like soggy
> > bandaids to me. Given they have a place where nothing else seems to
> > work (Ajax-ish file uploads), but i'd prefer to steer away from them
> > in this case if i can.
>
> > TJ:
> > That seems like a fairly solid idea. Same general concept of having a
> > second request object checking in on progress that the server reports
> > back, it just gets it from a relatively more reliable source (instead
> > of $_SESSION).
>
> > Alex:
> > Could you elaborate a bit, or point me to where i can follow up on
> > that? i'm intrigued, but i'm not deeply familiar with using the output
> > buffer effectively.
>
> > Thanks for the replies!
> > -joe t.
>
> > On Dec 10, 3:45 am, "Alex McAuley"
> > wrote:
> > > I noticed you were using PHP on the server side ... you can also use
> > > output
> > > buffering to achieve this in one request
>
> > > Alex Mcauleyhttp://www.thevacancymarket.com
>
> > > - Original Message -
> > > From: "T.J. Crowder"
> > > To: "Prototype & script.aculo.us"
> > >
> > > Sent: Thursday, December 10, 2009 8:38 AM
> > > Subject: [Proto-Scripty] Re: Progressive update messages from single
> > > request
>
> > > Hi Joe,
>
> > > It seems to me the simple way to do this is have the first request
> > > initiate a process on the server that keeps running when the request
> > > completes; the request returns an indicator of the current status and
> > > an identifier for the action.
>
> > > Your subsequent requests supply the identifer, which allows the
> > > server-
> > > side page to check the progress of the ongoing work matching that ID
> > > and report back the (new) status.
>
> > > People use things like this for showing progress bars for file uploads
> > > without using Flash, that kind of thing.
>
> > > HTH,
> > > --
> > > T.J. Crowder
> > > Independent Software Consultant
> > > tj / crowder software / com
Re: [Proto-Scripty] Re: Progressive update messages from single request
Joe.
Are you using ob_gz_handler(); or mod_defalte / mod_gzip ?
Also is it a winblows or *nix server
Alex Mcauley
http://www.thevacancymarket.com
- Original Message -
From: "joe t."
To: "Prototype & script.aculo.us"
Sent: Saturday, December 12, 2009 2:24 AM
Subject: [Proto-Scripty] Re: Progressive update messages from single request
Alex,
Thanks for the sample. i must be missing a piece somewhere though...
http://pastie.org/739926
>From that single Ajax.Request, the client delays, and after the PHP is
done running, i get the complete output in one block. What i'd
anticipated was that in each loop, the flush() would somehow send that
output to the client where it could be used, then the next loop's
flush would send another output to the client...
If i'm understanding it, Ajax is a single-request-single-response. i
can't output the current step a process is in as it happens. i can
accumulate them, as your model shows, and dump that out as a log, of
sorts. But in order to monitor progress of one request's processing on
the server, a series of follow-ups have to get feedback which the
original is providing on the side (as T.J. recommended).
Unless i'm missing something, which would be great if you could help
me fill that in. :)
-joe t.
On Dec 11, 3:29 am, "Alex McAuley"
wrote:
> in your ajax request file
>
> ini_set('output_buffering',0); // make sure the output_buffering directive
> is not set high
> ob_start(); // before anything is echoed to the screen
>
> for($i=0;$i<10;$i++)
> {
> echo('Printing Line '.$i.'');
> ob_flush();
> flush();
>
> sleep(1); // sleep for one second
>
> }
>
> ?>
> this will output a line every second for 10 seconds
>
> Hope this helps
>
> P.S if you use ob_gz_handler this may not work (untested using it)
>
> Alex Mcauleyhttp://www.thevacancymarket.com
>
> - Original Message -
> From: "joe t."
> To: "Prototype & script.aculo.us"
>
> Sent: Friday, December 11, 2009 1:00 AM
> Subject: [Proto-Scripty] Re: Progressive update messages from single
> request
>
> david:
> The buffer/flush path seems to be where this solution is heading.
> Don't ask me why, but iframes rub me the wrong way. With the evolving
> needs for more streamlined connections, iframes feel like soggy
> bandaids to me. Given they have a place where nothing else seems to
> work (Ajax-ish file uploads), but i'd prefer to steer away from them
> in this case if i can.
>
> TJ:
> That seems like a fairly solid idea. Same general concept of having a
> second request object checking in on progress that the server reports
> back, it just gets it from a relatively more reliable source (instead
> of $_SESSION).
>
> Alex:
> Could you elaborate a bit, or point me to where i can follow up on
> that? i'm intrigued, but i'm not deeply familiar with using the output
> buffer effectively.
>
> Thanks for the replies!
> -joe t.
>
> On Dec 10, 3:45 am, "Alex McAuley"
> wrote:
> > I noticed you were using PHP on the server side ... you can also use
> > output
> > buffering to achieve this in one request
>
> > Alex Mcauleyhttp://www.thevacancymarket.com
>
> > - Original Message -
> > From: "T.J. Crowder"
> > To: "Prototype & script.aculo.us"
> >
> > Sent: Thursday, December 10, 2009 8:38 AM
> > Subject: [Proto-Scripty] Re: Progressive update messages from single
> > request
>
> > Hi Joe,
>
> > It seems to me the simple way to do this is have the first request
> > initiate a process on the server that keeps running when the request
> > completes; the request returns an indicator of the current status and
> > an identifier for the action.
>
> > Your subsequent requests supply the identifer, which allows the server-
> > side page to check the progress of the ongoing work matching that ID
> > and report back the (new) status.
>
> > People use things like this for showing progress bars for file uploads
> > without using Flash, that kind of thing.
>
> > HTH,
> > --
> > T.J. Crowder
> > Independent Software Consultant
> > tj / crowder software / comwww.crowdersoftware.com
>
> > On Dec 9, 4:11 pm, "joe t." wrote:
> > > i think i've seen examples of this, but can't recall where, and could
> > > use some guidance.
>
> > > Obviously it's easy to handle a 1:1 Request/Response
>
> > > How can i do a true 1:many process? For instance:
> > > Client takes a single action which requires the server to perform 3
> > > tasks:
> > > * Query database
> > > * Generate PDF
> > > * Generate email, attach PDF, and send
>
> > > How can i respond to the client as EACH task is accomplished without
> > > ending the request chain?
> > > "Looking up your data . . ." (time-based dots as delay indicator)
> > > "Creating PDF . . ."
> > > "Email sent" (or failed, as the case may be)
>
> > > Is this done with HTTP 2xx headers? Recursive callbacks? If anyone can
> > > point me in the right direction (which include samples), i'd be
> > > grateful.
>
> > > Thanks.
> > > -joe t.
>
> > --
>
> > You received this message because you are s
Re: [Proto-Scripty] Re: Progressive update messages from single request
in your ajax request file Printing Line '.$i.''); ob_flush(); flush(); sleep(1); // sleep for one second } ?> this will output a line every second for 10 seconds Hope this helps P.S if you use ob_gz_handler this may not work (untested using it) Alex Mcauley http://www.thevacancymarket.com - Original Message - From: "joe t." To: "Prototype & script.aculo.us" Sent: Friday, December 11, 2009 1:00 AM Subject: [Proto-Scripty] Re: Progressive update messages from single request david: The buffer/flush path seems to be where this solution is heading. Don't ask me why, but iframes rub me the wrong way. With the evolving needs for more streamlined connections, iframes feel like soggy bandaids to me. Given they have a place where nothing else seems to work (Ajax-ish file uploads), but i'd prefer to steer away from them in this case if i can. TJ: That seems like a fairly solid idea. Same general concept of having a second request object checking in on progress that the server reports back, it just gets it from a relatively more reliable source (instead of $_SESSION). Alex: Could you elaborate a bit, or point me to where i can follow up on that? i'm intrigued, but i'm not deeply familiar with using the output buffer effectively. Thanks for the replies! -joe t. On Dec 10, 3:45 am, "Alex McAuley" wrote: > I noticed you were using PHP on the server side ... you can also use > output > buffering to achieve this in one request > > Alex Mcauleyhttp://www.thevacancymarket.com > > - Original Message - > From: "T.J. Crowder" > To: "Prototype & script.aculo.us" > > Sent: Thursday, December 10, 2009 8:38 AM > Subject: [Proto-Scripty] Re: Progressive update messages from single > request > > Hi Joe, > > It seems to me the simple way to do this is have the first request > initiate a process on the server that keeps running when the request > completes; the request returns an indicator of the current status and > an identifier for the action. > > Your subsequent requests supply the identifer, which allows the server- > side page to check the progress of the ongoing work matching that ID > and report back the (new) status. > > People use things like this for showing progress bars for file uploads > without using Flash, that kind of thing. > > HTH, > -- > T.J. Crowder > Independent Software Consultant > tj / crowder software / comwww.crowdersoftware.com > > On Dec 9, 4:11 pm, "joe t." wrote: > > i think i've seen examples of this, but can't recall where, and could > > use some guidance. > > > Obviously it's easy to handle a 1:1 Request/Response > > > How can i do a true 1:many process? For instance: > > Client takes a single action which requires the server to perform 3 > > tasks: > > * Query database > > * Generate PDF > > * Generate email, attach PDF, and send > > > How can i respond to the client as EACH task is accomplished without > > ending the request chain? > > "Looking up your data . . ." (time-based dots as delay indicator) > > "Creating PDF . . ." > > "Email sent" (or failed, as the case may be) > > > Is this done with HTTP 2xx headers? Recursive callbacks? If anyone can > > point me in the right direction (which include samples), i'd be > > grateful. > > > Thanks. > > -joe t. > > -- > > You received this message because you are subscribed to the Google Groups > "Prototype & script.aculo.us" group. > To post to this group, send email to > prototype-scriptacul...@googlegroups.com. > To unsubscribe from this group, send email to > prototype-scriptaculous+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/prototype-scriptaculous?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en. -- You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
Re: [Proto-Scripty] Re: Progressive update messages from single request
I noticed you were using PHP on the server side ... you can also use output buffering to achieve this in one request Alex Mcauley http://www.thevacancymarket.com - Original Message - From: "T.J. Crowder" To: "Prototype & script.aculo.us" Sent: Thursday, December 10, 2009 8:38 AM Subject: [Proto-Scripty] Re: Progressive update messages from single request Hi Joe, It seems to me the simple way to do this is have the first request initiate a process on the server that keeps running when the request completes; the request returns an indicator of the current status and an identifier for the action. Your subsequent requests supply the identifer, which allows the server- side page to check the progress of the ongoing work matching that ID and report back the (new) status. People use things like this for showing progress bars for file uploads without using Flash, that kind of thing. HTH, -- T.J. Crowder Independent Software Consultant tj / crowder software / com www.crowdersoftware.com On Dec 9, 4:11 pm, "joe t." wrote: > i think i've seen examples of this, but can't recall where, and could > use some guidance. > > Obviously it's easy to handle a 1:1 Request/Response > > How can i do a true 1:many process? For instance: > Client takes a single action which requires the server to perform 3 > tasks: > * Query database > * Generate PDF > * Generate email, attach PDF, and send > > How can i respond to the client as EACH task is accomplished without > ending the request chain? > "Looking up your data . . ." (time-based dots as delay indicator) > "Creating PDF . . ." > "Email sent" (or failed, as the case may be) > > Is this done with HTTP 2xx headers? Recursive callbacks? If anyone can > point me in the right direction (which include samples), i'd be > grateful. > > Thanks. > -joe t. -- You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en. -- You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
