Re: Are we not developers?

Well said Jon, I second everything you said.

Just to beat a dead horse, if Profound in general, and Scott specifically
found no reason to built their own JSON parser for a product that is 110%
dependent on JSON...then I certainly couldn't justify doing so.

Charles


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.

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

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