Re: Pete's web5250 was->Re: Business Developers was ->Re: IBM Gives RPG Devotees Their Own Café

I haven't read through all of the responses after this one yet, but that is exactly what I am talking about. Make it so each shop can drink their own UI poison, but also make it easy to switch to another horse in the event their poison almost kills them :-)

Of course the challenge is then having multiple implementations of the same framework be created in the first place and somebody from the community justifying the time to do it - of course vendors could jump on this bandwagon, which I would expect if it had any amount of take-off.

In the end it could come down to people using two implementations. One for the public facing sites where they don't want to require the downloading of a larger framework (i.e. JavaFX) and another for internal where they gain ease of use and better feel, by using the bigger download.
Aaron Bartell
http://mowyourlawn.com

Pete Helgren wrote:

Perhaps, and I am only guessing, that if the java servlet produced JSON then that could be consumed by a browser OR JavaFX, or theoretically anything else that consume JSON.
I don't know if anyone has decided to actually DO this, beyond the comments here, but we could start a new project in Sourceforge OR I could just make the project available through my Subversion repository. Or, we could all just go ahead an try it on our own and see who comes up with the best implementation.

Pete


Nathan Andelin wrote:

From: Niels Liisberg
JavaFX is actually another good argument for making the
5250 javascript proxy - JavaFX will just swallow the JSON
stream I am talking about....

Now I'm confused. Are we still talking about a 5250 interface? Accessing green-screen applications from a browser?

The earlier appeal of a JavaScript client seems to be getting lost in the shuffle. Getting back to basics, the appeal of a JavaScript client was to streamline I/O, and expose a green-screen interface that could be referenced from other Web applications running concurrently in the browser.

One problem with web5250 was that a 500 byte 5250 data stream was transformed into a 23K HTML data stream. Actually 23K was the compressed version. The actual amount of HTML generated by the servlet was probably double that. We don't need another HATS. We don't need another Webfacing. We need something more efficient.

The idea of a JavaScript client held two appeals to me. First, you could get back to dealing with a data stream that was more like 5250, and less like HTML, and thereby improve I/O performance. Second, a JavaScript client could expose an interface in the browser that could could be referenced from other frames. Say you wanted to automate the 5250 sign-on from an application running in a different frame. That would be pretty strait forward, using JavaScript.

Now it sounds like you're talking about Java code running in a JVM, and JavaScript running in the browser, and it seems to me that the interface is getting more unwieldy.

Nathan.