> Hi. Have you considered using the Web Server as a middle
> tier layer. The advantages are:
>
> 1. Scalability - just add another server if you need more
> processing power)
True in theory (though it raises other problems), but if you host on an
ISP, are they going to add another box because your app kills the CPU on
a web server with maybe hundreds of other clients running on it? Its
probably not too efficient on bandwidth either compared with a dedicated
thin client that can be tuned to be efficient on bandwidth. MS tend to
recommend that you start with grunty box with plenty of RAM just to run
IIs & serve (ASP) pages. Adding apps that crunch sound & graphics does
not help, (from personal experience <g>).
> 2. Ease of debugging (if you send you data in ASCII format)
I found debugging ASP/ActiveX/IIs/Java etc far harder than any Delphi
app (including 'thin' Delphi apps that use COM). Just adding extra
languages is always going to make it harder than a nice integrated
environment than Delphi. As for IIs locking COM objects until you shut
down the web server (unless you fight with MTS) - enough said.
> 3. Really thin client - all you need is a browser
I haven't tried IE5 yet but there is no way you can use the term 'thin'
when describing IE4 or Communicator. When using a client app written in
Delphi I can get the size down to ~500kb so that it will load & run Ok
on a low end PC - try loading IE4 & app up on a P90 with 16Mb to see how
slow it is.
> 4. Extensibility - write a Java/ActiveX component for use
> with the client browser
Nice but I develop using Delphi not Java. ActiveX is a nice for some
things (like Intranet apps) but downloading largish ActiveX over slow
connections is a pain - when I try a web side that expects me to
download ActiveX objects or plugins I generally don't bother. Thing
that killed ActiveX as an option for me was that my app talked to a DB -
therefore the client machine needed the BDE installed which defeated the
entire purpose.
> 5. Ease of setup - everything is setup on the Web server -
> the client only needs a browser
Sure is easier to setup but when you say 'only needs a browser', you
have to be careful about which browser as soon as you start using DHTML
then you start excluding browsers pretty quickly (and a lot of people
still use IE3 etc).
> 6. No need to write another module for "web access" to your product.
Can't say web access is a big selling point for me - anybody buy D4 for
the Delphi Direct thingy :-)
> 7. Great reuse of code - just change the HTML to suit
> different clients.
True - but managing this can get interesting...
> In this model, all your functionality is on the WebServer.
> If you need to upgrade your product, do it on the server, restart the
web
> application and everyone is upgraded - they can even be live on the
network!
Mmmh - one of the problems we found was trying to figure out a way of
doing updates on a 24/7 web app. You can down the web server but with
HTTP being stateless, things can get difficult determining if you are
pruning off users who are about to post.
I think web apps have great potential, especially for certain classes of
apps but I remain to be convinced that the tools are there yet.
Grant Black
Software Developer
SmartMove (NZ) Ltd
Phone: +64 9 361-0219 extn 719
Fax : +64 9 361-0211
Email: [EMAIL PROTECTED]
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
