Er, no.

Post #37,295 by pwhysall 5/3/02 12:10:45 AM Reply	Er, no. A JRE doesn't really qualify as a "fat client". HAVING to run Windows, now THAT's fat. Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #37,297 by tablizer 5/3/02 12:22:36 AM Reply	Obese (* A JRE doesn't really qualify as a "fat client". ) It ain't skinny. The biggest factor of a "fat" client is downloading programming code to the client. IOW, depending on the client executing app-specific code written in a Turing-complete language. My HR benefits were available on some Java applet written by (or for) a fairly large benefits mgmt company. It took about 20 minutes to download via modem to check on my HMO status. F that! ( HAVING to run Windows, now THAT's fat. *) But that is not a remote-app issue. IOW, besides the point. ________________ oop.ismad.com
Post #37,300 by pwhysall 5/3/02 12:41:11 AM Reply	Still wrong. You can get Java on a mobile phone or a Palm Pilot. [link\|http://java.sun.com/products/cldc/\|http://java.sun.com/products/cldc/] "At the heart of CLDC is Sun's K virtual machine (KVM), a virtual machine designed from the ground up with the constraints of inexpensive mobile devices in mind. Named to reflect that its size is measured in the tens of kilobytes, CLDC is suitable for devices with 16/32-bit RISC/CISC microprocessors/controllers, and with as little as 160 KB of total memory available -- 128 KB of which is for the storage of the actual virtual machine and libraries themselves." 128KBytes At what point do you concede? Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #37,353 by tablizer 5/3/02 1:13:38 PM Reply	You are missing the point. It is not the size of the VM that matters. Besides, the mobile-phone VM's don't have "normal" GUI widgets like scrollable grids. It is having to download app-specific programming code that is the problem. Mainly because: 1. Creates security problems when coders find ways around VM security. 2. Takes too long to download the app-specific code. 3. Enhances browser/client versioning issues because a "dynamic" language is more complex than a "static" one. 4. Allows business logic to go to the client, creating more security risks (similar, but not identical to #1 since one is harming the client and the other the biz). VM-destined code is relatively easily disectable. A server based solution does not normally allow one to see the biz logic code itself, including the compiled form. ________________ oop.ismad.com
Post #38,374 by static 5/12/02 8:39:37 AM Reply	I've got a better example. The bank with my day-to-day account uses a Java applet for over-the-web account management, like paying bills, viewing online statements, etc. I often use it from behind a V.90 modem. It doesn't take any longer to load than most pages on the web. I also found another applet from the same bank used to query their share price. Also quite small. Your HMO's applet is either far too large or their server was being very slow and very difficult. You should find an email address and tell 'em; they might be wondering why it's not very popular and have no idea why. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #38,481 by tablizer 5/13/02 2:41:25 PM Reply	Exception to the rule Your HMO's applet is either far too large or their server was being very slow and very difficult. I have had multiple slow experiences with different applets and different machines. If developers bust their balls, then yes one can make a smaller applet (usually by moving as much of the biz logic to the server as possible. Which brings up another issue: biz logic on the client is relatively easy to reverse engineer. Bytecode labelers and analyzers readily exist.) It is moot anyhow, because MS is pulling the plug on most Java in their browsers, making it even less consistent than before. The Java Applet model is pretty much dead.
Post #38,485 by imric 5/13/02 2:55:53 PM Reply	Huh? MS is pulling the plug on most Java in their browsers, making it even less consistent than before So - the divergent version of 'java.not' produced by MS is gone, with no return in sight - they aren't putting out a version that would be forced to actually be Java. This makes Java less consistent... How? Imric's Tips for Living Paranoia Is a Survival Trait Pessimists are never disappointed - but sometimes, if they are very lucky, they can be pleasantly surprised... Even though everyone is out to get you, it doesn't matter unless you let them win.

Welcome to IWETHEY!