Re: Is Client/Server Dead? Conference May 15th

In article <4lo73q$omk@nic.ftns.no> Nils.Myklebust@ccmail.telemax.no writes: >> peter@prospect.anprod.csiro.au (Peter Wiley) writes: >> ...snip... >> My experience to date confirms this. I have built (and am painfully >> debugging/tuning) a c-s system written in Progress. Compared to host-based >> on the same hardware, performance sucks. One to two orders of magnitude >> worse. >Is Progress this bad? Partly Progress, partly c-s going from fast disk/memory to the wire. Totally unloaded net, too; my system at home (SPARC2 -> P90 over 10Base2). Compared with Informix SE, Progress performance sucks, however. Don't get me started :-) OTOH, the Progress V8 GUI toolkit is easy to use & functional. More than I'd say about NE2. > >> Yes, you get pretty screens. This means it takes you 10 minutes to paint a >> screen and a week to debug it (event-driven means users do *stupid* >> things) as opposed to an hour to draw (being generous) and 2 days to debug. > >But some users can do things they never could before that they find extremly >helpful. And maybe another tool would be better? GUI screens good for EIS-type stuff and *some* data entry apps. Ideal for querying data. Another tool? No. The problem is fundamental to event-driven apps. Since the programmer can't determine the order of data entry (or even if the fields are filled in) you need to do *much* more error checking than in 4GL where you can *guarantee* the fields are filled in. > >> I'd like to say the solution is X displays on a host-based system but the >> punters^H^H^H^H^H^H^H clients won't wear it. Brainwashed by MickySoft. > >And it won't be event driven so no users can do anything stupid ;-) I wish :-) No, you don't solve this one. >And there will be no network trafic? A fraction. You're sending screen paint commands, rather than a lot of data. The data stays on the host. >And it will be faster to write and debug than on MS Windows? No. Problem is inherent in event-driven apps. It's Micro$oft's fault for making them popular :-) > >> About all I can suggest is pray app partitioning works and meanwhile >> overspecify the client h/ware. It won't help the bandwidth problem but at >> least it'll speed up local processing. >> >> Peter Wiley >> >> BTW, NT servers don't - compared to unix ones. IMO, anyway. >No, not currently. It's realy worth following though. Yes, I have one set up and keep the NT Server s/ware current. 2 of my clients have NT servers from DEC and Compaq with fast ethernet & scsi. My old SPARC 2 eats them all for lunch. My SPARC 5 more so. > >And in another post: >> wardk@fourgen.com (Ward Kaatz) writes: >> I love the mouse-driven controls that inevitably get put on GUI data *entry* >> screens. >> >> you have someone who sits at a terminal all day entering data and they have >> to pull their hand away from the keyboard to grab the mouse... >> >> but ya gotta admit, gui is so much sexier (and trendy) than that homely (yet >> efficient) 3270/5250/vt100 screen. very much worth the wait? > >First: For some purposes character interfaces are still the right choice. >However one of the most widespread misunderstandings is that every GUI program >requires a mouse. We have written several that don't, or at least not in the >main part of the program where the heavy dataentry is done. The GUI is used >simply because we are able to put more data entry fields on the screen and >the user is much more happy than they where with the character based interfaces. >And the speed of operation is no problem. Agreed. Some of my pure data entry screens drive by function keys and ALT key combinations to avoid mouse ops. It can be done. Usually isn't, though. Lazy programmers? I field-test my code with the users to pick up these sorts of improvements. Peter Wiley