Re: Dynamic Web Page

jschumac@uns-dv7 (Joel Schumacher) wrote: :Nick Nobbe (nnob@loc.gov) wrote: :: John, :: I heard an interesting solution to this problem at the Informix :: World Conference in Chicago. Apparently, their Advanced Technology :: Group has software libraries that they install at your web site :: that solves the problem of spawning processes for each database :: request - one connection, multiple requests, one process (Don't :: quote me; speak to Informix). I believe security is not implemented :: in the new package, which once it's working corrrectly, may be :: given away. :From what I understood is, yes, an application is spawned off to handle :your client and it does stay running (at least for a time). Fine. :I believe they said that it passes the communications off to a separate :TCP/IP port. When the browser communicates again, it uses this new port :and talks to the running program. :The running program mostly just sits and listens until it is triggered :again, then it serves up new data in response to the browser's actions. :If the browser never talks to you again (or waits too long), your program :times-out after a while and goes away. Also very fine. : If the browser does communicate :again, the port it's trying to talk to will have dissappeared because no :one is listening anymore and you get a communications error. Stupid. This sounds like it's done by someone to preoccupied with the internal workings of things. Obviously the program should have been restarted. If the connection wasn't completely stateless they may have a problem, but it should have been solved. :For anybody who got too wordy on the On-Line Conference Evaluation form :in Chicago, you'll understand what I'm talking about. Several people took :too long filling out their forms and the evaluation form program died. :When they finally sumbitted their form, they got TCP/IP errors. This should make it obvious why I said simply stupid above. : If you :filled out the form really fast, it worked like a charm. A bleach charm to my mind. It has a clear defect, and should not be released to any users. :In any event, I don't think that this is exactly what is being asked for. :As was stated in another post, the nature of the web doesn't let you :"push" information to a browser. This, (although some people probably :think it would be great) would be very annoying. Imagine trying to :follow a thread, while the last URL keeps throwing up the current :price of Informix stock on your browser. :A browser is a connect, get some info, disconnect, then display/run type :of operation. Well, I'm sorry, but this is a far too simplistic view. Of course the regular "old fashioned" web pages behave in this way. Java doesn't however. And a java applet sent with a page can do a lot of other things. Of course - *of course* - the "last URL" doesn't "keep throwing" up anything. That would have been bad, and how on earth should it work. What can be done, and allready can bee seen in demo versions at least, is a Java applet that establishes a connection to some kind of a server. This is a regular fixed (virtual) connection using one of the TCP/IP protocols that sits there (at the users site) waiting for the server to send (push) something. When something is received it is displayed somhow by the Java applet. Of course it may (if allowed by the user) store the data, or do anything else with it as well. The current regular behavior of a Java applet is to disappear as soon as you "follow a thread" and go to another page. It is conceivable, although I don't know whether it's possible right now, that the Java applet stayd there functioning, while you keep on browsing. Then I could get my stock quotes continously while doing other work. This is currently possible by opening another browsing window. The part I don't know if it is possible is whether this can be done automatically by the Java applet. The Informix solution sounds like a solution to a completely different problem. Namely the problem (most often seen when CGI is used) that a server program has to be restarted every time a page request hits the server. This may make up for a lot of programs being started all the time on the server. It seems to be a general trend to try to find other solutions to this where server programs keep runing, so they at least do not have to be restarted every time. The same server program should then be able to serve many requests from different users simultaneously. From what you say here, the solution from Informix seems to be less than partial to this problem. :The new Informix software is a sort of, "Hang on, I'll get back to you :later" sort of thing. You still connect, get info, and disconnect, with :the exception that if you connect again, you can talk to the same app :that serviced you previously because you've been pushed off to a private :line to communicate on. :You still can't push new info to the browser side real-time. As stated above, you use Java or similar solutions for this. Nils.Myklebust@ccmail.telemax.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company