Re: Are we not developers?

On Jun 3, 2020, at 12:27 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Jon,

Thanks for your feedback. In regard to your question about how I define
CGI, I was referring to the IBM i CGI interface (the pool of Apache HTTP
server Jobs that run IBM program QZSRCGI, that call user-written programs,
which normally use procedures in service program QZHBCGI to receive HTTP
requests and generate HTTP responses).

I eschew the IBM i CGI interface for a number of reasons, which I've
written about in the past. I don't want application code interfering with
the operation of the HTTP server (coding errors and what not). I don't like
the idea of a potentially very large pool of Jobs that call application
programs based solely on which Job might be available at the moment. That
ultimately leads to the activation of all applications in all HTTP Jobs -
like a built-in memory leak.

Instead, our web applications are submitted and go into a wait state,
receiving HTTP requests from the HTTP server through a plug-in. Our web
apps may be submitted from the command line, or scheduled, or submitted
when users click menu items.

At any rate, the CGI interface that is implemented in YAJL would be of no
use to me.

HTH,

Nathan.




On Tue, Jun 2, 2020 at 2:35 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Comments in-line Nathan.

On Jun 2, 2020, at 1:08 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

On Tue, Jun 2, 2020 at 10:22 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx>

wrote:

"I'm developing a JSON parser."

May I ask why Nathan? This sounds like reinventing the wheel when there
are at least three really good parsers already available.

No problem. BTW, which three parsers might you be referring to? YAJL must
be one, for sure. I agree that it sounds like reinventing the wheel, but
I'll share some of my rationale.

YAJL for sure. SQL has it, so does powerExt, ILEastic, and RPGNextGen.
That is not counting the PHP, Java and Python routines that all run on IBM
i.

Broadly speaking I need a JSON parser to consume web services as well as
support web-service clients. That's a big deal to me. But in response to
reinventing the wheel, let's take YAJL as an example. It implements a CGI
interface, whereas none of our web applications use CGI.

YAJL has _added_ an interface to stdin/stdout the base is designed to
consume/geenrate JSON from/into a file or variable - so I don't understand
your comment here. So you don't use Apache at all? Or how else do you
define CGI?

Also, I need to support the parser. As I've reviewed the YAJL C code, I
didn't feel comfortable enough with the code to support it. It also
includes a procedure that converts the JSON to UTF-8 prior to parsing,
which I question. The parsing logic to me looks like it could be coded to
perform more efficiently. I'd like to come up with something that

performs

better, even though my standards for performance may be higher than most.

JSON is to all intents and purposes intended to be coded in UTF-8. If I
understand correctly it is actually a requirement for all JSON parsers to
support UTF-8 so I really don't see why that would be an issue. Why do
_you_ need to "support" YAJL? It is an open source project widely
community supported on multiple platforms. Problems (which are few) are
quickly resolved. Scott has wrapped it in RPG to make it easier to use and
his code is not only well written but pretty easy to understand. Worst case
scenario Profound will write support contracts for it. It is blazingly
fast, I know that it outperformed all the other options that Scott looked
at when he first operated it. You don't worry about supporting RPG - YAJL
is just another tool.

I have several ideas that would streamline the API. For example reading
JSON arrays directly into RPG data structures, comparable to data-into,

but

implemented with a procedure interface instead.

DATA-INTO _is_ (or can be) implemented as a procedure interface. YAJL has
DATA-INTO and DATA-GEN hooks both of which work beautifully and very
quickly. I've been using them a lot lately and they work well.

SAX parsing within YAJL is very confusing to me. I think that can be
improved significantly.

SAX type parsing with most anything is confusing <grin> but that's why I
use DATA-INTO unless I only need a fraction of the data.

--
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