Brad Clements wrote:

>
> 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.

Previously I've had good success in writing java 1.1 (so it runs in the
current browsers) as a thick client, talking back to the web server over
html. You basically get to write a substantial portion of the
application to run at the client side. The first incantation ran talked
through a cold fusion back end. Since then I have regularly (for a
heavy or nice looking app) used the java client plugin, and run the back
ends as servlets. Next time I need to write somethings like this, since
I have java at both ends, I think I would now also use serialization
more heavily in the communictions layer.

I would still generally have the client talk indirectly through the
web/app server to the database rather than directly to the database.
It's a good security/transaction/input validation checkpoint and can
then be written in whatever you like.

Thicker java client reduced posts to the web server to 1/5 of what they
were for the same application in html forms.

The java plugin is a 5meg download so you need to be careful where you
use it.

Cheers

Mark

--
Your database needs YOU!
http://firebird.sourceforge.net