Hello Bart, Bart Busschots wrote: > Andreas Hartmann wrote: >> Bart Busschots wrote: >> >>> Hi Andreas, >>> >>> Like any other web server a Java based web server use the Common Gateway >>> Interface (or CGI) for sending information between the client and the >>> server. This is a request-response protocol which is driven by the >>> client and not the server. What you are trying to do is have the server >>> push information to the client and ask the client for information when >>> the server wants it. >>> >> >> What I'd like to do is: >> Client starts an application, which begins to run and sending output. This >> output is parsed and formated by the webserver before it is sended. If >> there is a request for an user, there will be some input-forms created, so >> the user can react. Meanwhile, struts has to hold the application running >> (waiting for input) in the background, while the user responds to the >> questions. This should be best cgi: Browser started a request and it got >> an answer on which the user responds with a request again. And so on. >> >> The tricky question is: >> Can struts send data to the client (after they have been requested from >> the client), during they are produced or begins the sending of data when >> all data is existing which is to send? Which classes could be used best to >> reach this approach? Is it possible to achieve this behavior with the >> action-class? >> > I really don't think Java is a good language for this kind of thing. > Shelling out from Java is messy and not really that powerful from my > experience.
Yes, it's much easier with perl to communicate with external processes, you are certainly right. But it should work with java, too. A first try makes me hopeful to solve this problem. I thought some more time about growing output - it is no more a must but nice to have feature. > I don't know of any mechanism in Java for interacting with > another process in the way you are looking for. My gut feeling would be > that Perl is a better language for this kind of thing. >> I thought about an applet too, but this seems to be very expensive for now. >> > How do you mean "expensive"? It needs too much time to code it for now. Additionally, there are dependencies to the client (installed java version) which I really want to avoid. > Bart. Kind regards, Andreas Hartmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
