I think it is not very clear what we are thinking thin-clients are.
The finest and thinnest of all clients are X clients on UNIX
and Citrix-MetaFrame etc on Windows. Problems:
+ X has a network protocol that is not efficient and not internet-friendly
+ MetaFrame is optimized for network use and can be run over a WAN
but it underuses client presentation capabilities, putting a lot of
stress in
the server
Then you have HTML 3.2 thin clients, but the functionality is so poor,
we must keep looking for alternatives.
Java applets are heavy in use of client RAM, network download is a problem,
browser compatibility is a headache, client installation raises doubts about
being real thin clients, and then any Java programmer can put business rules
in his/her applet code.
HTML 4.0 clients look good because RAM use is what the browser will use
anyway, and DHTML, HTML Data Binding, XML, RDS etc provide
lots of functionality and user interactivity. Of course the programmer can
abuse this power and put business rules in the client, but then it is a
question of
good SW engineering to avoid it.
Conclusion: IMHO a good SW developer can develop usable clients
with DHTML/RDS/etc if the user can standardize on IE4/5.
The same SW engineer will face a lot of problems
with JDK 1.1 clients because of RAM use and download times.
Of course some functionality just cannot be done with HTML 4.0
but if it can be done, we want to do it. MicroSoft is doing a
great job expanding the limits of what HTML clients can do
-- guess why? ;-)
BTW in my experience there is little risk of business-rule violations
because of DHTML browser incompatiblities. The client either
works fine or does not work at all. It is possible to check USER_AGENT
headers at the server or use several client side tricks to work around
incompatiblities.
It's a shame Navigator is so behind in implementing W3C standards
so that we must rely on IE4/5.
Regards
Javier
>> >I though we ruled out the fat client solution several years ago.
>> Microsoft
>> >is re-releasing the Client-Server paradigm, and the fans are cheering!
>>
>>
>> I'm afraid you are a little off-mark. This thread was about Windows DNA
>> and *thin* client development using IE5, DHTML, RDS and other
>> MicrsoSoft technologies.
>
>I don't consider the DNA-way of building "thin"-clients produces real
>thin-clients. Okay, they're thinner than for example applications and
>applets, but they produce clients that behave curiously much like
>Client/Server-clients. These applications typically works in this way: get
>data from server (RDS), interact with user (DHTML, Data Islands), process
>data in accordance to some business rules (Data Islands, DOM), return data
>to server for update (RDS again).
>
>Of course, the DNA/RDS/Data Islands-architecture produces great
>user-interfaces. And hopefully the developer realizes he/she's really
>building a fat-client-system. Differens is that you download the code on
>request (as if you were downloading an applet, hopefully takes a bit
shorter
>time though :).
>
>What if the user has a different version of Internet Explorer that behaves
>differently than the one you built the system for. Okay, the _best_ thing
>that can happen is that the system won't work. If you're really unlucky the
>system will work anyway but will behave incorrectly in accordance to your
>business rules, and produce inconsistent data. The same thing will happen
if
>Internet Explorer caches some pages, and don't cache others. Then you've
got
>a real mess.
>
>These are the problems that occured when working in the
>Client/Server-paradigm, I'm really sad that Microsoft has reintroduced this
>paradigm. And even worse is that they're marketing it as a
>thin-client-architecture (I were not aware that they did, but it seems so
>from your mail).
>
>I say: Never trust a client! :)
>
>> But since you raise the fat client issue, Win2000 has a revamped
>> Installer that makes automatic network installation, repair and
>> upgrade of client apps so easy and versatile it takes away a lot of
>> the reasons to develop so called Java thin-clients -- a Java applet
>> may be one of the fattest clients you can find, with above 20 MB RAM
>> usage including the browser, and well above of 1 MB of
>> downloadable code each time the client starts.
>>
>> Anybody who deploys Java applets must be considering several schemes
>> to install part of the client in the user's workstation, be it CAB files,
>> PVCj or Marimba/Castanet. Windows 2000 Installer is just that.
>
>The Java-applet is a "pretty fat"-client solution as well. And the
>Marimba/Castanet, Weblogic ZAC (Zero Administration Client), Windows 2000
>Installer is a great way of handling the administrational overhead
>associated with the fat-client solution.
>
>To be fair I don't consider the Java Applet to be a good way of producing
>easy-maintenance applications either.
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
