Re: Re: Inserting CGI code in script tag

Sorry about the confusing post. I only put in a fragment of the code and that is where some of it arises from. Essentially I have a module that does the following:

Takes a subroutine as an argument (usually one that takes a long time to run)

Forks off a child to process the subroutine code while the parent creates a temporary "analysis in progress" html page (that refreshes every so often). When the child is finished executing it creates another html page that prints any output from the subroutine, and then overwrites the "analysis in progress" page with the content of this page thus ending the refresh.

I get tired of looking at that screen and wanted to give some kind of progress update and incorporate it into the module. So, in addition to the subroutine used to perform the actual work, I want to take another subroutine as an argument that can be used to give some kind of status on the update. In my case I wanted it to print the number of records that have been inserted into a db of the total number using some DBI code. What I could do with the second subroutine is create a temporary CGI fine that the refresher page redirects to. However, I was hoping to just be able to have the progress subroutine print to the browser directly, that is without needing to generate this temporary cgi file. That is the basis of my question. There may be a much easier way to do this, I am not sure. I hope this makes things clearer.

Also, I was using the script tag to point to the cgi program for historical reasons. The cgi script outputs document.write commands so that part of the script is fine. However, I should just use the redirect as it is easier.

Thanks again.

-jim

Comment on Re: Re: Inserting CGI code in script tag

Replies are listed 'Best First'.
Re (3): Inserting CGI code in script tag by dmmiller2k (Chaplain) on Oct 24, 2001 at 21:42 UTC
The problem with this kind of thing in general is that the web is request/response based. Server-push (that is, having the progress subroutine print to the browser directly) is difficult to get right. I've had some success with a similar problem by storing the process id of the forked process (or some other identifying value) in a session record (perhaps in a database table), and passing the key to that session record as a parameter to a progress script (e.g., `"test_progress.cgi?session_key=whatever"`). The progress script can then use the session key to look up the process id (or whatever), check whatever it needs to check, and regenerate the "in progress" page with a redirect to itself after some amount of time. When the process is complete, the progress script can immediate redirect to a third script (or perhaps the original one, with a different parameter to identify the new context) for display of the output, which must have been stored somehow by the forked process, in a location identifiable by the same session key--I often use a generated filename in /tmp, with the hostname and process ID of the background process somehow incorporated in the filename, as the session key. There can be irritating reliability (i.e., timeout) problems with your original idea of rewriting the page from the forked process. It may or may not work, depending upon how long the background process takes and other factors beyond your control, such as browser dependencies, server-side loading, etc., and whether or not the progress page itself contains `</BODY>` and `</HTML>` tags. dmm You can give a man a fish and feed him for a day ... Or, you can teach him to fish and feed him for a lifetime	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re (3): Inserting CGI code in script tag
by dmmiller2k (Chaplain) on Oct 24, 2001 at 21:42 UTC

The problem with this kind of thing in general is that the web is request/response based. Server-push (that is, having the progress subroutine print to the browser directly) is difficult to get right.

I've had some success with a similar problem by storing the process id of the forked process (or some other identifying value) in a session record (perhaps in a database table), and passing the key to that session record as a parameter to a progress script (e.g., "test_progress.cgi?session_key=whatever"). The progress script can then use the session key to look up the process id (or whatever), check whatever it needs to check, and regenerate the "in progress" page with a redirect to itself after some amount of time.

When the process is complete, the progress script can immediate redirect to a third script (or perhaps the original one, with a different parameter to identify the new context) for display of the output, which must have been stored somehow by the forked process, in a location identifiable by the same session key--I often use a generated filename in /tmp, with the hostname and process ID of the background process somehow incorporated in the filename, as the session key.

There can be irritating reliability (i.e., timeout) problems with your original idea of rewriting the page from the forked process. It may or may not work, depending upon how long the background process takes and other factors beyond your control, such as browser dependencies, server-side loading, etc., and whether or not the progress page itself contains </BODY> and </HTML> tags.

dmm


You can give a man a fish and feed him for a day ...
Or, you can teach him to fish and feed him for a lifetime

[reply]
[d/l]
[select]