> Jim Starkey wrote:

> The strategic goal of Firebird should be to support completely
> dynamic web sites. But 100% dynamic page generation requires
> a great deal more database access (in number of queries) than
> a simple but dumb ASP page. Any institutional latency (such
> as an intermediate server) gets multiplied by the number of
> database interactions until the delay is no longer acceptable
> to the human at the browser, and the site fails.
>

I've been lurking on this list because I've had nothing to say. Hope the
following is sufficiently on-topic (apologies in advance)

--

I agree with the Jim's statement. I've developed several commercial
websites based on the Zope "web server". Every page in Zope is
dynamically generated.

All of these sites use Interbase/Firebird as the back-end database.

One of my customers is an importer/exporter. Every page his customers
look at contain large lists of shipment records, tracking details, etc.

Zope caches SQL requests based on the sql statement and parameters.
Zope can also cache the dynamically generated page and refresh it based
on pre-selected HTTP headers and stuff (we're not yet using this feature).

But when it gets down to the wire, Interbase/Firebird is going to be the
component limiting the 'perceived performance' of the system.

How quickly a small result set is returned is important in this application.
Fortunately our selects are well structured so we don't have to resort to
using things like "select TOP n".

We're using SS architecture. Some sites have Interbase, some have
Firebird.

--

We now need to move beyond simple HTML forms for data management.
The issue I face is what avenue to take:

a) C++ Builder or Delphi thick client using Interbase components

b) Java client (using straight Java or Jython) and Interclient

c) ADO 2.5 with DHTML and RDS (I'll have to write the code to create
XML recordsets from Interbase/Firebird)

d) XML-RPC or SOAP with DHTML

At this phase of development, I have complete control over the client and
can mandate what browser is used and can deploy a thick client
application. Later on, I probably won't have that option and will require a
"browser hosted" interface.

No decision has been made yet. Discussions on Interclient architecture
are of interest to me because of my future development needs.

Thanks for reading this far.



Brad Clements, bkc@... (315)268-1000
http://www.murkworks.com (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com AOL-IM: BKClements