Re: Why use PHP? What are the disadvantages?

[hr@xxxxxxxxxxxx]

I think what Scott ment was that the "handler" would be a/work like a 
"Screen Scarper" because even though RPGOA removes the restrictions of 
1920 char buffersize (24x80 characters) it still works the same way - 
it communicates through a "flat" interface (the buffer) and it will 
require a persistence program structure where jobs waits for the client 
to repond.

RIA's requires a service oriented server architecture and the argument 
that RPGOA is a weel know way off communication with a client is the 
samt as to say - we want to maintain a CARDIN/CARDOUT 80 col punch
card approach to make a 5250 interface - just because people at that
time (when 5250 appeared) was used to it.

Henrik




Nathan Andelin <nandelin@xxxxxxxxx> 
Sent by: web400-bounces@xxxxxxxxxxxx
21-04-2010 17:39
Please respond to
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>


To
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
cc

Subject
Re: [WEB400] Why use PHP? What are the disadvantages?






Regarding the idea of RPGOA being a screen scraper, I can see the point, 
to a degree.  The file on the "F" spec may be a *DSPF, and the device type 
may be WORKSTN. But it's also meaningful to note that new handlers take 
control BEFORE, and INSTEAD of the traditional routines that generate and 
serialize a 5250 data stream.  The interface is also much more flexible 
and modifiable in that handlers can define additional data structures to 
be passed, in conjunction with normal data buffers.  That opens new 
functional possibilities that were unavailable to traditional screen 
scrapers.

I like the design of the interface.  I like the idea of having a 
consistent and familiar interface to communicate with contemporary devices 
in addition to traditional devices.  My biggest concern is that IBM's 
packaging it as a new product with a separate price seems rather 
contrived.  Third party vendors may say to customers, well you can evoke 
our open(), close(), read(), and write() procedures directly, or if you 
want to use the traditional open, close, read, and write op codes, you can 
license that capability from IBM.  But the functionality is the same.  So 
what is the sense of licensing an additional interface from IBM?

Open, Close, Read, Write op codes are already inherent in the RPG 
compiler.  Why make them a separate products, now?  Is this a precedent 
for charging separately and individually for new op codes and %bif()?  If 
so, a number of programmers will just create and evoke procedures 
directly, rather than using op codes and %bifs() in the compiler.

-Nathan.




----- Original Message ----
From: "BButterworth@xxxxxxxxxxxxxx" <BButterworth@xxxxxxxxxxxxxx>
To: web400@xxxxxxxxxxxx
Sent: Wed, April 21, 2010 8:37:29 AM
Subject: Re: [WEB400] Why use PHP? What are the disadvantages?

I think Scott may have been being a little sarcastic when he said RPGOA is 

a "screen scraper" technology, but I will let him speak for himself. You 
are still generating a web UI via the medium of RPG I/O and opcodes, which 

seems less intuitive to me. I haven't seen your product or Profound 
Logic's product and don't mean to belittle them. If they can be used to 
re-configure existing (monolithic) heritage applications with little or no 

effort, then I do see an advantage there for companies who have neither 
the time or resources to re-write their applications. As regards new 
development, however, it still seems to me we could already do everything 
(including session management and security) using system APIs, service 
programs and procedures before RPGOA. I was using Valence merely as an 
example. I'm not familiar with all the third party tools that are 
available for RPG development. 

My point about WYSIWYG tools and Javascript is that regardless of RPGOA, a 

RPG developer is going to have to learn one, the other or both to do web 
development. RPGOA and associated third-party tools are not going to 
provide a silver bullet such that developers can develop web UIs/apps in 
the same manner as green screen apps and get a decent web 2.0 UI. If a 
developer wants to use WYSIWYG tools, code-generators, etc., that's fine, 
but then one becomes limited to/by the tool vs. doing the actual coding. 
So it seems to me some forethought has to be given to how established the 
tool is, what kind of backing it has in the community, etc. before a long 
term investment is made. The same is true for language frameworks, but the 

popular ones generally have a much larger developer base (e.g., Zend, 
Dojo, JSF, .NET, etc.) and provide more resources for trouble-shooting and 

research.

Blake



I think you're wrong on a couple counts.  First, RPG OA is not a screen
scraper, it completely changes the datastream so that the handler can
deliver an appropriate persistent connection.  You can write new code
without changing the interactive development paradigm.  For developers who
find persistence and host (server) side control to be an advantage, then 
it
is a game changer for the platform.  Secondly, Valence has come up with
nothing new.  The looksoftware smartclient has supported new forms with no
associated host screen, RPC, database access, and web service consumption
since R7.0, which was delivered in 2005.  Certainly extending one's skills
is important, but learning a WYSISYG design tool is really not painful, 
nor
is vbscript or jscript for that matter.  Take out the pain of middleware
development and you've got a great new opportunity.  The application
portfolio of the IBMi is so replete with heritage code that is not viable
for replacement that RPG OA will likely add another decade of life to many
applications.  Viva la RPG.

Pete Isaksson
petei@xxxxxxxxxxxxxxxx
Business Development Mgr
www.looksoftware.com
+1 678 494-5465 office
+1 678 662-2400 cell