Re: Dynamic Web Page

John P. Zucchero wrote: > > > Imagine yourself in a large brokerage office. Your task is to design > > a system to allow brokers to pull up client portfolios in one window > > and in the same window show the current trading prices in REAL TIME. > > The web is stateless, i.e. You make a connection, get your data, > end the connection. This is a good solution for the web to not > cause saturation, but for a database app, it is bad. > > --John > Uhmm, since both John and Dave are from Informix, I thought I should combine my response in to one posting. First, there is some confusion as to the *web*. Think of the web as a decentralized source of multimedia information ie data, connected by a very large network. The tools which work on the *web* also work for a client server environment. Second, John is correct in stating that the web is *stateless*. However, both John and Dave miss my point. My scenario was a client server application which demonstrated the need for the ability to *push* data from a datasource. It is an extremely good example of a database application. I think that Dave has spent too much time within Informix. (He is too valuable to be let loose. [This is a serious comment.]) Dave has been trapped in to a linear thinking about Interner/Intranet applications. Since I don't know John I can't comment. John seems to be under the impression that this is a poor database example. Maybe that's why Sybase is used within the financial community more than Informix? Any application which requires a data store is a *good* example of a database application. The database is required to store and track the opening price, the ask and bid spread, and the last trade price for each stock. The last trade can be considered an update of that record. If this application is part of an active trading system, then the trade must also be captured. The bottom line, is that the data is coming from a real time feed. Any time you have *real time* data, you need to push it from the database. Think about it. If you pull data, you have to request it. That means, that each client has to request 'has this stock changed' for each stock it is currently tracking. So if you have 10 stocks per client, and 100 clients active, that's 1000 requests which need to be answered in less than 1 second. (Anyone care to guess how many stocks are traded within that 1 second?) OF course, most clients have more than 10 stocks in their portfolio, and there are more than 100 brokers in a brokerage house..... It is far easier to push the data. Granted, you have to have an intelligent client to listen for the data and ignore the data it doesn't need. This calls for C , Java , Javascript or something like that. Other real time applications which require some form of database could be found in Medicine, Military Aviation, Chemical treatment / processing, Pharmacology, Systems Management, Finance/Banking ..... I hope that I have made my point clearer. When dealing with an active data set aka *real time* data, you can't rely on a request, you need to publish the data. That is why TIB is sucessful and that there are other proprietary systems which perform publish / subscribe information. Hope this helps. -Mikey PS. Hey Dave, what have they been keeping you on these days?