Re: Niels IceCap 5250

[Pete Helgren <Pete@xxxxxxxxxx>]

I second that Nathan.  Most shops want to transition, rather than tear 
out and replace.  So anything that makes the move more comfortable will 
be more successful.  Getting 5250 application data inside the browser is 
a good first step.  Once you have them inside the browser, you can 
leverage all the tools to make that experience better.  That was the 
whole idea back in 2002 when you and I were working on AEE (Application 
Execution Environment - a menuing/portal system for those of you who 
weren't part of the company). 

And to come full circle, if the 5250 data was in a standard format, 
consumable by web client applications, then the two *would* converge.  
You might have an emulator piece that would present something that 
looked more 5250-ish while next to it, or within a frame of it, you 
could have a Rich UI application.  Similar to a "portal".

I am more and more intrigued by this idea.  I had only looked at the 
5250 data through HTML eyes, but using JSON or XML to make it all less 
verbose, it could provide a handy way to leverage existing 5250 
applications.

Watching with interest.

Pete


Nathan Andelin wrote:
> > From: Joe Pluta
> > As I get more involved with the Rich UI architecture of EGL, it becomes 
> > increasingly clear that trying to extend the 5250 paradigm is not going 
> > to work in the rich world.
> >     
>
> You seem to be making two points with one statement.  First, that attempting to turn a 5250 application into a rich one won't work.  Second, that a "rich world" is on our doorsteps.
>
> Both points are valid.  But I'm still interested in some continuity, and a gradual transition from 5250 to rich.  And a rich UI is not needed for all applications.  Sometimes a simple prompt precedes a data area update, or batch job submission, for example.
>
> The thing that would be nice, would be to deploy both rich and 5250 under a single portal, to support both interfaces during the transition.  One sign-on.  Both environments.  A means of toggling between either.  A means of communicating between both.
>
> Nathan.
>
>
>       
>