Re: Saving the System i: Fight Rather Than Switch

[Tom Liotta <qsrvbas@xxxxxxxxxxxx>]

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