Yep, that POC approach is the way to go. Helps to figure out where the
complexities and failure points will be in short order without doing full
adoption of anything during rapid development.
The cool thing about having it built on top of telnet (or at least an
implementation built on telnet) is that other telnet based systems could
re-use a lot of the infrastructure (i.e. big mainframe COBOL shops). It's
been awhile since I have worked on IBM mainframes (close to 10 years, and
that was in college), but I believe I accessed the systems via hard-wired
terminals so I am not entirely sure if they operate via telnet - anyone
know?
>This will keep the eye on the ball: "Is it possible to build a solid
JavaScript proxy that consumes the 5250 stream and provides JSON"
Another "eye on the ball" I think would be fun to pursue would be a JSON
processor written in Adobe Flex. The reason I say this is because the
code would be compiled into a SWF instead of needing to be interpreted
each time like JavaScript (or are browsers getting smarter these days and
"compiling and saving Javascript for later"?) Not that Adobe Flex is any
better than Silverlight (or insert other favorite client runtime here),
but it has popularity going for it.
Aaron Bartell
http://mowyourlawn.com
Niels Liisberg wrote:
Nathan wrote: The "pluming" that I referred to in my earlier post was a
menu sytem, and an API that can establish and maintain persistent onnections
between browsers and a virtual terminal servers, if that would help.<<
Thanx Nathan - Actually it might help. Did you write in Java?
Aaron wrote: The TN5250 project (note there is no "j") could be ported to
the AS400.\001<<
I was looking at it - cool stuff. The view port and the TCP/IP is
irrelevant. But the stuff "in between" - the 5250 parser can be used..
However still need to swap the TCP/IP with the virtual terminal api before
it runs native on i5/OS.
Or how about this .. proof of concept:
Keep the TCP/IP + parser as it is. Then build the JSON generator on top +
and add super tiny webserver (i have boiled down icebreak that runs
linux/windows - 200 lines of code).
This will cut to the chase - keep the TN5250 as it is communicating with the
system i, and the JavaScript JSON transission server/client can be built on
top of that.
This will keep the eye on the ball: "Is it possible to build a solid
JavaScript proxy that consumes the 5250 stream and provides JSON"
If that works - then the rest is just pluming. Moving it to a native system
i job using the virtual terminal is not trivial, but it is straight forward.
Best regards
Niels Liisberg
IceBreak Chief SW Architect
System & Metode Technologies
Haandvaerkersvinget 8, DK-2970 Ho/rsholm
Phone: +45 70 20 36 10
Fax: +45 70 20 30 11
Direct: +45 45 177 055
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Nathan Andelin
Sent: 22. december 2008 16:13
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Pete's web5250 was->Re: Business Developers was ->Re:
IBM Gives RPG Devotees Their Own Cafe
From: Niels Liisberg
In the end of the day - I will be very grateful for any plumbing
that is using the virtual terminal.
I'd check first with your IBM contacts. They may be able to suggest a
better API than the virtual terminal interface. It sounds like Zend and Look
Software have had some pull with IBM.
Virtual terminals are NOT much different than socket programs that connect
to telnet ports and send / receive 5250 data streams.
From the source code that Pete Helgren posted it was clear that the tn5250j
interface insulated him from dealing directly with 5250 data streams.
tn5250j parsed the data stream and generated high-level collections of
screen elements; very object oriented. I can see how something that would
be easier to work with.
On the other hand, the virtual terminal api would let you bypass Java
middleware entirely, and streamline communication between browsers and
virtual terminal servers.
Pete Helgren had a noteworthy idea about deploying 5250 interfaces alongside
new Web applications within the same portal, using a shared menu system.
Something like that helps smooth the transition from 5250 to more modern
user interfaces. But the web5250 interface is too slow in my opinion.
Most 5250 applications communicate with telnet servers which communicate
with 5250 terminal emulators. A virtual terminal server on the other hand,
could bypass telnet servers and communicate through the HTTP server, with
browser clients instead.
The "pluming" that I referred to in my earlier post was a menu sytem, and an
API that can establish and maintain persistent connections between browsers
and a virtual terminal servers, if that would help.
Nathan.
midrange.com
