Re: Are we not developers?

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.

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