Well, I think you're choosing JSON for the wrong reason... You seem to
be picking it because you've been made (or forced into) a bad decision
of using stored procedures for this, and JSON will save you a few bytes
(but, it won't really solve the problem.)
If it's important to use stored procedures, I'd be fighting to have
"normal" parameters instead of a JSON or XML string, and I'd be
splitting up the work into many stored procedures so that each can be
called at the right time.
Or else I'd be fighting to eliminate this clunky stored procedure model
and use web services instead.
If all that failed, would I choose JSON over XML from your perspective?
Hmmm.. based on what I know of you, I think I'd probably pick XML,
because it's easier to code in RPG, since RPG has built-in opcodes to
That's rather different from my perspective, though. For me, JSON is
easy to handle in RPG, I did all the research to find the best JSON
processor I could, and thne I ported it to IBM i, and then I wrote an
RPG-friendly front-end for it. So after all of that, doing the actual
JSON coding is quite easy for me, and I'd probably use it. On the other
hand, I haven't yet written any docs for it... so I hesitate to suggest
it to you.
On 9/20/2013 2:18 PM, RPGLIST wrote:
So Scott let me ask you, if you were looking at this from my perspective--
take it you would serioulsy consider using JSON over XML?
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact