Choosing the right frontend (was: new era to exploit universal server)

This has become quite an issue around here. And the choice is not at all easy, given the current market/technical uncertainties and computing requirements in our shop. Even though our is one of the biggest RT departments in Italy, we're a pretty small firm (about 40 employees/consultants, not all being users). I'm the only superuser/DBA/developer/whatever around. To make things worse, that's not my only duty: in fact I don't have much time to spend programming. In all, costs and developing times are extremely important issues. To complicate matters, we have far too many client types (PC's - DOS, WFW & W95-, MAC's, various Unix Boxes from different manufacturers, and even 2 PDP's!) for client/server solutions to be a good choice. Tool costs (due to the many dev licenses needed), tool (un)availability on all required platforms, differences between ports or difference in releases that have been ported (think of new era!) and other considerations like dubious ODBC security, ODBC drivers reluctant to work correctly (from what I gather from the many complaints posted to cdi) etc, etc all rule out c/s. Note that it wasn't our choice to have such an eterogeneous computing power. Many of our boxes come tied to some medical machinery: gamma cameras, MR or CT scanners (one of the PDP's), RT planning systems (the other), RIA/IRMA counters to name a few. What's more the manufacturers themselves are reluctant to allow us to install products that they don't know / understand / trust or think might interfere with their sw. This rules out practically everything except standard intranet solutions. And even this is sometimes a problem, in particular on DOS (i.e. no Windoze) pc's. Nor is it feasible to put near to each machinery dedicated computer a pc (as many a manufacturer has suggested!) and say to the medical / paramedical staff "Turn to this pc whenever you want to access patient data" With this kind of scenario, java *might* fit nicely. With just a java aware browser and a URL, any workstation (ok, ok, let alone the PDP's!) could safely interact with our existing DB's with no platform specific problem and conflict whatsoever. The only doubts still open regard JDBC, in particular on security and app validation. But what about investment protection and user (re)training? These are very important issues. We're simply not in the position of throwing our 4gl code out of the window and replace the old apps with others written with a new tool. For some of our users cs knowledge starts and ends with the bunch of 4gl apps they've used so far. Stupid as it may seem, a retraining due only to user interface change is seen as a problem. Others, on the other hand, are keen to see at least a face lift. The current feeling is that our 4gl apps are user friendly, and intuitive. If only they could use the mouse! We use a CUA interface, with pull down menus, dynamic accelerator keys and the like, all thanks to a message driven CASE (whose virtues will not be told here!) that eases a lot 4gl development. What we really only lacks a graphical interface. And that's not an easy thing to add to 4gl apps. Now, something that I have in mind is some kind of a smart telnet interface. Something that will add buttons, menus and 3D looks to my app with only the effort of some java code, a new termcap entry, and no 4gl code recompilation. And again, java looks just appropriate for the task. Before you say, I'm not the first to have this idea. The guys at 4j had it before me. And Some guy at the University of Geneva has already written a 3270 emulator geared towards his bibliographic tool (you'll find it with a quick tour at gamelon). Working out the details shouldn't be too difficult. My little java app (let?) should scan output produced by the original 4gl app and create the appropriate objects according to the euristhics outlined below (these haven't been thought in detail, so please be patient :-) - anything on the first (I'm assuming an option menu line first!) line is a horizontal menu, each option being items separated from other items by two white spaces. If there aren't any, then that's just a header. Menu / input / construct comments could go on a nice 3d status bar on the bottom. - anything with a border is a window, except for those that start right below a menu item, which are pull down menus (not a 4gl feature, but many programmers, me included, have written their own routines to simulate them). The only notable exception could be a box wide as the screen (I like fgl_drawbox), which should only create a 3d border on the main window. - if 4gl uses function key labels as defined in termcap/terminfo (something that I'm yet to find out), creating a button for each accelerator key shouldn't be that difficult. Granted, I'm imagining something that's geared towards my way of developing 4gl apps, and other problems have to be solved, like there isn't a way of obtaining direct cursor control in inputs et similia (but this isn't necessary a bad thing), and menus with ambiguous keys are not easily dealt with, but all in all the idea is beginning to look pretty neat. And given java ability to load anything given an URL and to play sounds and display graphics, 4gl could go multimedia (Who wanted to write that "Igor" program?!?) by just embending URLs in the original 4gl app output! (Uh Oh, this sounds a whole lot like when Siemens has to convince me that designing a SCSI controller for PDPs & Unibus, just to sell CD WORMs with their CT scanners, is a technologically sensible move) Keeping my feet on the ground, this approach has many advantages: 1) costs nothing (Hey! Of course I do find my work valuable) 2) it's platform independent 3) works equally well with c and rds 4) has no security or app validation issues 5) has very limited maintenance issues (the browser reloads the applet automagically!) 6) like 4j, permits the use of the same code no matter the terminal emulator used 7) The appearance of the 4gl app can be easily customized. Think of button icons being uploaded by the applet. 8) Do the job once, and all 4gl apps get the face lift 9) It's a good occasion to give java a try So why don't just use 4j's 4gl? A few good reasons: I don't want to find out that my additions to 4gl can't be used with their product, and their telnet app is not available in all the required platforms. Isn't that enough? Of course, a face lift may even convince me that it's still worth using 4gl for new app development. But in that case, wouldn't we all really appreciate if Informix could just stop loosing time with new era and gave 4gl a good polish? (No need to go thru the entire list of suggestion collected by JL, Informix. Just give us the essentials!) What do you reckon? Have I gone mad, or is this a viable solution to protect code already developed. I'm keen to get a debate going on this topic. Thanks for having gotten this far. ciao, marco ____________________________________________________________________________ rem radioterapia, which I immeritately manage, seldom agrees with what I say marco greco (Catania, Italy) Work: marcog@ctonline.it rem radioterapia 39 95 447828 fax 446558 (was mar.greco@agora.stm.it) Achea 39 95 503117