> Hi Grant,
> I think you and Dennis have managed to open an *interesting*
> debate between you about the option of Web development for n-
> tier apps. We've been doing serious Webapp development for
> nearly four years now, but until today, I didn't realise just how
> hard it was for us <g>.
I was trying to open a debate on the issue because I think alot of
programmers are interested in web app's - hell I am, but I think the
official MS line of using ASP + COM etc can lead to nasty problems. Its
only my point of view of course and I welcome correction (maybe off-line
- ie offtopic group if other Delphi list members are not interested). I
didn't mention WebHub or any other approach simply because I don't have
personal experience. At the moment I am playing with some simple IP
socket based distributed apps and although it feels as though I am
re-inventing the wheel it looks more like what I want.
<snip>
> And Dennis' scalability criterion is an important one. With round-
> robinning, multi-server/multi-app-instance support and other such
> features, there are some truly remarkable scaling opportunities
> attainable with good Web back ends, none of which depend on
> the power of the PC on the client's desktop.
Yep - scalability is a big selling point in web apps - especially
Internet as opposed to Intranet apps.
<snip>
> On the whole, though, I agree that debugging a Webapp is harder
> than a regular GUI one -- the special nature of HTTP and its (non)
> management of connections makes for some "interesting"
> issues. Even dodging the things you listed above, and with
> WebHub easing our way in several areas, I'd rate this as one of
> the more expensive development issues. But Dennis' comments
> are quite true in that the communication stream is easy to
> intercept, check and interpret, far less so than (say) Midas
> socket streams, or whatever.
Have to agree - nothing worse than debugging binary streams...
> > just adding extra languages is always going to make it harder
> > than a nice integrated environment than Delphi.
>
> I don't add any extra languages <g>. WebHub is Delphi, and
> OOP through and through.
Ok - as I say, I have not had experience in WebHub but if you are going
to toe the MS line on Web Apps (as we all must <g>) you are going to
have multi-language projects.
> as NS 1.2. I've never liked any of the MS browser line (IE5 has
> *some* promise) but supporting them all is not a big problem.
Have to disagree coming from a ASP background - for a rich UI in HTML
you really start to need DHTM
l, Javascript etc in order to handle common UI tasks such as right click
pop up menus, combo's filled on the fly, tabbed notebooks etc.
> With that in mind, being able to say "point your (existing)
> browser at this URL, and the app will work", is *truly* thin in
> several important senses. So long as their machine has the
> power to run the browser, it has the power to do WHATEVER the
> Web site is designed for.
Very cool when it works - makes demostrating your app to overseas based
clients very easy as well.
> I'm with you on that. But I see a future for Java applets (not so
> much ActiveX) on the Web. ActiveX has a place in Intranets, for
> which many of these "web as middleware" 3-tier apps are being
> be developed, however. In other words, while there are solid
> reasons why you or I might not download a browser automation
> component in order to to use a public Web site, that doesn't
> preclude their effective use for real-world solutions on dedicated
> or high-bandwidth networks.
>From my understanding ActiveX objects may be held in cache but otherwise
are downloaded every time you hit the site - even with plenty of
bandwidth that sounds slow when you start getting big obejcts.
> That depends, of course, on your choice of database, and
> linkage. We run DB-manipulating Web sites and clients all the
> time without the BDE, on either browser or server end. (Caveat:
> we're not doing any writing to a DB on the *client* machine, but I
> expect that's not what you intended to imply).
The approach we took was to use ASP -> COM Middle tier -> DB on the
server which saves having any sort of database access layer on the
client, but if you are using say an ActiveX client app that executes on
the client machine then how does it link to a database (say SQL7 or
Interbase), on the server?
<snip>
> You *may* have been looking at the wrong tools <g>.
Most probably but then if WebHub is the only answer then the options
seem pretty limited.
> In contrast, you seem to be saying "it's too hard to create a full-
> featured *public* three-tier type Web-based application" (hence
> discussions of ISP hosting issues; browser size and choice,
> browser automation and so on, as if the whole world HAD to be
> the target user community, in contrast to the in-house scenario
> noted above). Considering such public web site issues makes
> your case quite supportable, although I hope my comments
> above have suggested it is *not* necessary to put it straight into
> the "too hard" box if you have the right tools...
Its certainly not _too_ hard - I have done it as have others. I just
wish for better tools all round - certainly early 98 with InterDev 1.0
etc I felt that there were lots of pieces (including training) missing.
If I have to develop another web app in the near future I certainly
would look at WebHub as an answer but its probably not an option for MS
shops.
> For more on why *I* think WebHub walks around many of the
> issues you presented, see my white paper at
> http://www.href.com/webhub/white.html -- it's nearly two years
> old, now, but 90% of the issues you raised are covered in it...
Read it last year.
> (And heck, we haven't even discussed non-HTML (full-GUI) client
> solutions that employ HTTP and tools like WebHub supporting
> the server middleware! Maybe Robert Loof will chime in with
> something on that...)
As I say, I am more interested in distributed net apps than web server
based apps at present - ie all the apps being clients & servers.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
