× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Nathan,

Not interested in attracting developers....
Maybe an explanation as to what inspired me to do this...

Based on my past experience in the last 20 years at well over 10 different
shops (onsite)...

Many rpg shops i have been in have been structured in a way where the sys
admin and architects may put frameworks
in to place that the RPG developers work on. Those frameworks keep the
developers in a functional area that allows
them to efficiently do their relational database development with minimal
framework issues and distractions.
However, this whole separation of duties thing can be a bit of a
frustration for us developers that are anxious
to get into cross platform development, and where our organization has not
provided any sort of efficient way to
allow us to write our IBMi programs to move data to others.

This coreiRST product is designed with that in mind.

Having the right framework for this is critical... again so that our
developers can focus on translating business needs
to functional software, instead of getting lost in the weeds of "how will
this data get off our platform"?

So I would expect this coreiRST product be at the hands of an IBMi shops
lead architect or administrator. With this
very simple yet powerful framework, it can be deployed to allow your
development team to create API's with no learning curve
at all. (hence no rpg code shown in video - you already know it... though
we could all learn more sql/json).

I'd highly recommend producing these backend API's using json/sql. It is
incredibly clean and
efficient. Also I should add that this framework is NOT dependent on
that. If you can create a *PGM on the system, then
you can use this framework.

It is highly doubtful that if you worked at any shop I have been at
(thought times are a changing)... that you'd be able to develop a
backend RPG pgm that manipulates sockets so you can send data off
platform. Ain't happenin.



Jay



On Mon, May 4, 2020 at 5:49 PM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Jay,

It's nice to see you making improvements. Your video is missing something -
the RPG code required for receiving HTTP input and generating HTTP output.
You've done a nice job of automating HTTP server configuration, using a DB
table to link URLs to RPG programs, and viewing log activity.

But if you're interested in attracting developers, I think you need to show
the code for a web service.

With regard,

Nathan.


On Mon, May 4, 2020 at 3:15 PM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

so if anyone would like a look at coreiRST I just completed a video on
it.

https://jeffersonvaughn.com/Corei-RST-REST/Webservice-Framework-Product/

or if you prefer a detour...

https://youtu.be/ptVh2ag0mAI

I also actually spent a lot of time today "re-facing" something things.
product avail for demo on my website.

Hope you enjoy.

Jay

On Mon, May 4, 2020 at 12:09 PM Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

I've been reviewing both RPGAPI from Daniel Long and COREIRST from Jay
Vaughn this past week. I'd like to comment on and question both. Please
see
inline below.

1) this project runs inside a VPN as long as the future ones, so no
need
for https so far


We have customers who began thinking they would access their web
interfaces
via VPN then later changed their minds in order to save the
administrative
hassles of managing VPN clients, user authentication and user
authorization. They ended up implementing HTTPS even though they were
not
planning on doing that initially.


2) a single running program like this may be scheduled to start/stop
at
specific times


In regard to "stopping" RPGAPI applications, have you found a way to do
that? Except for locating the Job and killing it with the ENDJOB
command?


3) such a program may be easily debugged even by those who don't
write
full
free RPG programs yet


Good point. In contrast to CGI interfaces, there is only one Job. So
there
is no problem locating it and debugging it. On the other hand, what do
you
do when many concurrent users are accessing the service concurrently? A
CGI
interface scales by starting multiple instances and dividing workloads
between them. Will a single-threaded Job support all concurrent users?


4) the analysis of this project is a work in progress with the
client,
meaning routes and routes' parameters are still changing (with IWS
this
means the whole configuration must be set from scratch every time
such
a
change takes place)


Yes, that is a problem with IWS. But Jay was referring to his CGI
interface, which doesn't need to be stopped or restarted when routes
are
added or removed. Actually, the RPGAPI interface would need to be
stopped
and restarted, which seems like something of a disadvantage in
comparison.


5) RPGAPI routes are much more similar to those in use among web
developers


In COREIRST the route are defined in a DB table, whereas with RPGAPI
the
routes are hard-coded in the application. Is that really an advantage?


6) as arrays of arrays are implemented in many responses, writing
JSON
responses is needed in any case


In regard to the format of generated responses, I don't see any
difference
between the two. They are equally capable. But both are limited to
about
32K.


In this first development stage, I follow both the Vue front-end and
the
RPG back-end, and I am trying to code RPG service programs for them
to
work
when called both via IWS and via RPGAPI server to keep future paths
open:
when the whole procedure will reach a good level of consistency, I
will
consider how to enhance some developing aspects. The decisions I make
are
not perfect, I know it, but I need to balance both the complexity
that
comes from the client's requirements, which imply more innovative
solutions, and the current state of the art of ICT people and
environment
in general.


I have a hard time imagining anyone using IWS for REST web services if
they're comparing with RPGAPI. Just seems like a lot less configuration
and
administration with RPGAPI. Plus better performance.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.