nikita,
As others have pointed out, it's trivial for a cgi (in whatever language)
program to interact with another program. Happens all the time in perl
where the script either fork/execs, systems, or backticks a program.
That being said there's one part of your question that puzzles
me - the user can contitue interacting with the program via the html page
... c++ does not finish after the first output.
This is going to be quite difficult due to several reasons:
- http is a stateless protocol, the next "interaction" knows nothing about the
previous "interaction"
- most cgi's tend to be single processes - http request sent, cgi script
forked by server, cgi run, response sent, cgi ends/process ends
Even if you get around those limitations with state tricks and apache embedding (mod_perl),
web servers tend to be
farms so you may have to coordinate across web serves too (or
at least ensure the request always goes to only one machine in the farm
- hooray for mod_rewrite/mod_proxy).
That being said, I think what you want can be done but it's going
to take a lot of planning and a lot of design.
-derby
update: Now that I think of it, this would be kinda neat
to set up as a SOAP server. You would wrap the c++ in
a SOAP server and then the cgi-script would just be a SOAP client.
You may still need to keep state with your cgi-script but you wouldn't
need to worry about the lifetime of the c++ program (at least not in
your web server/cgi world). | [reply] |
Cookies, of course, can allow you to add state management to a HTTP transaction. This might be a way to handle the page to page state maintainance.
However, cookies can be dangerous (or irritating) if poorly handled and your CGI program is non trivial. http://web.stonehenge.com/merlyn/WebTechniques/col61.html is merlyn's fine, fine article on how to use cookies well. Even if cookies aren't the appropriate solution this time around, if you are writing alot of CGI scripts you ought to read it.
Cheers,
Erik
| [reply] |
Sure, that's the whole purpose of the CGI module (and the various modules that inherit from CGI). As long as your C++ code can interact appropriately, there's no practical limit to what Perl can do for you... that's why Perl is known as a glue language.
Of course, it couldn't hurt if you could be a bit more descriptive of your particular scenario and/or C++ code (not the code itself, just its purpose). Nevertheless, there is a glutton of good resources for Perl/CGI programming online and in print. Check the Reviews section of PerlMonks for detailed suggestions.
-fuzzyping | [reply] |
Check out the Inline modules. Inline:CPP may be of use for your current problem, but they're all fun to work with :).
| [reply] |
If the c++ is relatively simple, and you can identify the
external variables needed for input, then swig might
be an alternative to InlineCpp.
http://www.swig.org
That would let you run it as cgi fairly easily. | [reply] |