Re: Thinking out loud about a new RPG web framework

["Guillermo Andrades, CPI Software" <gab@xxxxxxx>]

at least for my records, comment here that there is the "same" approach we
are developing in our try of web based gui for RPGIV.
even we "was" thinking about the possibilities of being able to converting
"complete" programas changing EXFMT for other operation.
our main functions (RpgForWeb.com) are working very good when using "normal"
non-persistent approach.
the persistent way is below the name RpgToWeb.com, includes wizards for
create and even converts dds to html and the mechanisms for using "real"
persistence, using (glub) dtaq..., this approach is nearly 90%, the full
program conversion is below 80% and vey hard.

as others, we start some way of using browser gui for RPG for the lack of
this as an original IBM, that is the real solution for RPG developers.
Of course our try to comment this way to IBM was to nowhere..

unfortunately we're developing in a totally incorrect language and country,
this in another history.

I envy the open-source idea because this the people wants: "free as a beer",
apart from doing all the work with a few click.


Best Wishes,
Guillermo Andrades
http://RpgForWeb.com <http://rpgforweb.com/>






On Thu, Jun 5, 2008 at 8:58 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

> What if you could create a programming experience that allowed the RPG
> programmer to code just like they were communicating with a green screen as
> far as program state is concerned, but instead be communicating with the
> browser?
>
> Here's what I am thinking (I need to get it out of my head before it
> explodes, and thanks Jon Paris for starting my wheels turning in this
> direction, and to Joe Pluta for introducing the JSP approach to this):
>
> Have a "mother router" program that sits under Apache and all it does is
> receives in HTTP requests from the browser and based on a hidden form value
> (or cookie storing a session ID) it would appropriately "write" that
> request
> to a keyed data queue where a program is waiting for that specific session
> key.  Upon receiving the data queue entry, the business logic program
> processes the contents of the HTTP post by evaluating the action that was
> taken (just like how green screen programming checks for the function key).
> It then determines what to respond with and goes back into a wait state on
> a
> data queue "read" (just like waiting on EXFMT).  The benefit in this case
> is
> that all global variables, open data paths, and SQL cursors were able to
> remain open and stateful as it relates to that specific users interactions.
> The data queue layer is basically acting as the replacement mechanism for
> EXFMT.
>
> The issue I had previously is that each web browsing user had their own job
> on the iSeries which could potentially become burdensome for a public
> website with thousands of users coming in.
>
> With V6R1 RPG is now completely thread scope safe.  This means that you
> could (in theory) spawn a new thread for each web browsing user within a
> SINGLE job on the system.  The purpose behind this would be to save on the
> number of jobs on the system, though I have nothing to quantify the
> resource
> savings of threads vs. jobs, except for I imagine spawning a thread is
> "cheaper" than creating a job.
>
> Does anybody know if the RenaissanceFramework operates in a similar
> fashion?
> (http://www.renaissanceframework.com/)
>
> Obviously this only solves one of many problems RPG programmers face with
> web UI programming.  The other thing I have in mind is a way to compose
> forms (not necessarily HTML) using an "intermediary syntax".  The
> intermediary syntax would basically have things like field x/y coordinates
> along with size, color, onclick actions, etc.  The intermediary syntax
> would
> be  rendered to the client based upon a "Render Kit" (stealing from JSF
> terms here).  In the case of talking with the browser, the intermediary
> syntax would be rendered to HTML using CSS positioning and Javascript to
> spawn user events back up to the server.  In the case of talking to the
> desktop, the intermediary syntax could be rendered to XML and the desktop
> thin client could be written in Java/.NET/etc and spawn events back based
> on
> user events.
>
> I am starting to prove out the different concepts by writing smaller pieces
> of code to document the proof of concept.  For example, at the bottom of
> this email I have included screen_stack.html and css_positioning.html
> showing a couple of the concepts.  My next step is to do the data queue and
> "mother router" proof of concept.
>
> I am starting an online place to start progressing on this initiative at
> http://www.assembla.com/wiki/show/RPGUI
>
> Of the upmost importance is that this project be open source and free from
> vendor lock-in.  Let me know if you would like to assist with this
> initiative and I will give access to the assembla project.
>
> Thoughts anyone?
>
> Aaron Bartell
> http://mowyourlawn.com
>
> screen_stack.html: http://code.midrange.com/95f4583917.html
> css_positioning.html:  http://code.midrange.com/240aed98ca.html
> --
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.