Click on any item to view...
Why then, did Screensurfer originally deliver using HTML instead of a dedicated Java terminal emulation applet, which could format the screen identically to a standard screen and provide compatible keyboard mapping? (note that with Version 2 both of these incompatibilities have been significantly reduced, as Screensurfer V2.0 has HiFi HTML and the SSKeys keyboard re-mapping control).
Screensurfer is not a "status-quo" solution
When an organization implements new technology, it does so for any number of reasons which generally include: cost savings, increased productivity and competitive advantage.
Screensurfer can provide all of these benefits, whereas a dedicated Java terminal emulator cannot. If a new tool or technology is to introduced, it will require new development, support and training for all involved; shouldn't the most be gained from such an effort?
A dedicated Java terminal emulator, such as one provided by OpenConnect, can provide a quick and secure delivery of terminal emulation sessions to users at popular Web browsers. For existing users, where current network costs can be significantly reduced by switching from a VAN (value-added network) to the public Internet, a Java emulator may just be a "slam-dunk" in terms of justification as a replacement for the current emulator and network.
But the Java solution doesn't integrate with the Web browser; it simply uses the browser as a fancy menu system and as a "host". Once launched, the Java applet continues in its own primary window frame, separated from the browser and its standard user interace; interconnection with other Web information sources and "back button" (built-in review) are both not available.
In addition, the Java solution incurs a large download overhead the first or subsequent times it is initiated; this is not particularly well suited for "public" Internet access or even Extranet use.
How much are you really improving applications?
Enhancing existing Java solutions requires graphical user interface coding in Java, and all enhancements will execute at the client (fat client syndrome). This leads to a tendancy to simply leave the applications alone, and use the Java solution as simply another terminal emulator.
This leaves the entire access to host applications "same as it ever was"; if you are implementing Web access to mainframe applications, an enhanced 3270/5250-to-HTML solution such as Screensurfer offers far more benefits over time, and provides a far better client approach particularly for tapping the huge opportunities in the ExtraNet and Internet realm.