|
M Lazarus wrote:
Without working out the technical and design details, here's what I'd like to see, as a starting point: The ability for the system to output to a browser without any changes to the program! IOW, the system s/b smart enough to know that I've got a browser vs. a 5250 device at the other and of the pipe and output a browser data stream instead of a 5250 data stream.
Mark: Saying the concept makes it all seem "As easy said as done."And I suspect that the one-way "output a browser data stream instead of a 5250 data stream" side is pretty easy. I'd guess that getting the browser to work in opposite direction would be where the whole idea would fall apart.
The design of HTTP effectively negates the possibility. No matter what, your programs would have to undergo significant structural change to react to the stateless nature of it. It cannot be as easy as EXFMT.
Simple question -- How is the [Back] button handled? Technically, in CUA terms, I suppose it _ought_ to be handled as <F12>, but browsers won't know that. Further, not all DSPFs even declare F12 handling.
After [Back] is handled, what about any selection from the browser session history? How would the case of selecting three screens back be handled?
The point is that display file objects are pretty intelligent. Their intelligence is exercised when combined with a controller/device combination or a non-trivial emulator. DDS display file keywords control keyboard shifts, valid inputs, error messages, etc. Review the various DDS keywords and attributes to remember what IBM has to contend with.
In order to transfer the intelligence into a browser, the client must be downloaded. Browsers will simply refuse to work the way we want them to work otherwise. Every DSPF will download new client control code to customize the "browser/emulator" code that would necessarily be downloaded at the start of a session.
I'm pretty sure there's a limited subset of DDS that we'd need some general agreement on in order to spec out what would be expected from IBM, but IBM would need some convincing before they supply it. If it actually became popular, what would happen to their revenue streams from the products they sell that compete with it?
We had Workstation Gateway. How widely was it used? That was about as full a subset of DSPF DDS as anyone could expect for a trial offering from IBM (for free!) but it was pretty much scorned. How long has it been since you've seen it in regular use... at sites that haven't upgraded past its availability, of course.
AFAIK, IBM has already given us exactly what you're asking for and it wasn't good enough for the market. I'm not sure how much more could possibly be done by IBM to make it work, but it wasn't good enough. I'm playing with a WSG session on an old 5.1 system right now, and I gotta say that it looks pretty good in terms of what's been asked for so far. But it apparently wasn't good enough.
What was missing that doesn't require a client download? Should IBM have kept WSG alive? Who would use it? Was there significant usage?
Tom Liotta
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
