XMLSERVICE enable JSON protocol about xmlservice HOT 35 CLOSED

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

For the archives...

"xjservice" is formally named db2sock.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

The new version of xmlservice toolkit is in progress. A new project for xjservice will be created.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

nodejs toolkit ... direct with JSON ... eliminating the transformation step xmlToJson

Yes.

when?

Last year too busy. I am hopeful to get to it early this year.

design

I am arguing with myself about performance vs. flexibility.

Here then, take a listen to my brain ...

RPG is a good thing ...

First, made a few mistakes in old XMLSERVICE that hamper performance a bit. We can fix this. However, IBM i elephant remains in the room. To wit, performance has little to do with XML vs. JSON. In fact, both XML and JSON are simply 'big strings', transported to XMLSERVICE 'parsed' into IBM i specific structures with whimsical data types like packed decimals, zoned decimals, not to mention EBCDIC characters that are not present client side language (php, ruby, .net, python, etc.). 'There are more things in heaven and earth, Horatio-you-linux-laptop-language-now-on-IBM-i, ... including Nodejs ...'.

Today, XMLSERVICE is extremely simple for any new IBM i language to 'toolkit' to send 'strings' over popular existing transports like REST (xmlcgi), and DB2 stored procedures (xmlservice/plugxxx). Aka, we know from experience with new IBM i languages, most anyone can write a language specific 'toolkit' to use XMLSERVICE with REST/DB2 transports. The current 'big flexible string' pattern establishes a encompass all uses local and remote, database or rest, etc., regardless of string be JSON or XML.

It is all about speed ...

... abandoning all rational flexibility thinking to favour ultra high speed only (cough), an argument can be made to simply run directly memory-2-memory calls similar to python iLibCall (not exactly right yet, not fast enough yet, but similar). Essentially, forget 'toolkit' flexibility, instead, requirement is run as fast as possible local only IBM i with no additional processes or protocol (no db2, no http, nothing). This favours an approach of going directly from PASE<>ILE using existing system calls _ILECALL, _PGMCALL, etc. (*).

(*) In all fairness ...

PASE provided system calls for _ILECALL, _PGMCALL, etc. from day one. The IBM i community acceptance of these APIs without a 'toolkit' was, well, zero. However, python driver 'toolkit', now uses these system calls for the iLibCall class (memory-2-memory calls). Mmm ... maybe ... The Times They Are a-Changin ... but we have had these PASE system calls from 1997 ... mmm (bell bottom jeans in then?).

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Mmm ... January came and left ... maybe make that February.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

I forgot to respond to this secondary consideration (and i can practice change bar).

Cool idea. I don't know if database is the storage solution I'd pick and instead maybe store it in the same location of IFS socket descriptor for when "stateful XMLSERVICE" is being accomplished?

Ok, "graph" data store, DB2, file system, shared memory, etc., maybe any/all mentioned is cool.

Because if somebody is looking to cache program structure definition then surely they would already be using persistent XMLSERVICE calls, right? I am thinking out loud and have only started to ponder this caching approach, so take this comment with salt.

np. As far as persistent/private connection, i think most important "persistent graph" could lead to the ultimate in performance any recalls (2nd+ time), without much work for toolkit writers (simple language toolkits). Basically, "just send the data", and, regardless of which type of XMLSERVICE connection is running, the "prepare graph" would be ready with all the _attributes fully described, aka, "graph" recalled from DB2, or IFS, or shared memory, or socket, etc., then "apply" the data (example below).

Aka, for example (not actual), just send a JSON array with data bits, similar to existing xmlservice idea ...

#!shell
{
"pgm": {
"_name": "ZZSTAR",
"_lib": "FARAWAY",
"_graph":"/tmp/zzstar.txt",
"__records": ["start wars movie times", "14:23:00", "discount reptiles only", 5.29]
}
}

Where _graph, could be anything ..
 "_graph":"IFS,/tmp/zzstar.txt"
 "_graph":"DB2,savem/graphs"
"_graph":"SHM,/tmp/sharedgraphs"
"_graph":"sock,10081"
(or something like this)

... but again ... no promise ... life to have, not just computer science ...

from xmlservice.

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

Put a greater than sign as the first character and then paste the sentence/text you want to quote.

For example:

> my comment plus change bar on left, followed by your response (looks cool)???

would look like this:

my comment plus change bar on left, followed by your response (looks cool)???

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Off topic ... this issue tool (editing) ... how are you creating change bar "re-play" of previous comment, aka, my comment plus change bar on left, followed by your response (looks cool)???

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Maybe wait until mid-late January (vacation soon). I feel still in honey moon stage with new graphing technique. It all seems pretty nice, but i have nagging feeling things are too easy ...

from xmlservice.

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

Nope, XMLSERVICE needs to do it's own thing, because, well, it is essentially a compiler.

After learning more of your reasoning, I agree.

hopefully able to add contributes (a goal despite the Oger i appear in these forums).

Maybe a good starting place for XMLSERVICE contributions is to have the community develop unit tests for the new JSON interface. I see you have RPG. Should we create a Bitbucket issue for RPG JSON unit tests to see if somebody grabs it?

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

The obvious hope is only toolkit writers will need to understand the syntax and then every-day-programmers can simply use the toolkit.

Yes.

BTW -- For people reading, this json format discussion is at toolkit provider level, aka, sausage making, aka, don't look here if you are simply grocery shopping for toolkits in your favourite language.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Oh, for RPG code geeks, i forgot to mention ... using graphing, i removed nearly all of plugxml (very tiny now), and, also plugjson is tiny (new). The old plugxml version was messy, did too much, and, evolved to entropy (as happens). No excuse, just second time around is looking much easier to read, and, hopefully able to add contributes (a goal despite the Oger i appear in these forums).

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

repeat:

I wish to avoid confusion, a json "art" running battle is likely to go on until delivery.

For people following this discussion ... until i say different ... If you want to see what XMLSERVICE input JSON will look like, simply cut/paste any current XML document generated by any language 'toolkit' for XMLSERVICE into this tool provided by "code beautify experts".

http://codebeautify.org/xmltojson.

Until the code beautify model fails (not expected) ... or ... i see a very convincing "functional" reason to change, that is, not eye of beholder beauty (irrelevant), above link should generate XMLSERVICE "parse" of the XMLSERVICE JSON support.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Yes, we must create our own parser.

So, blunt it is, Klement parser is generic, simply parsing json chunks into "little chunk" name/value nodes will not help. Frankly, it doesn't really understand much about the actual resulting data parameter geometry (can't line up parms for a call). Perhaps worse re-assembling output of Klement tool is left to the student %char(12.52), aka, convert to string yourself Dude, ouch, times hundred of data types, multiplied by infinite parameter and data structure geography.

In fact, not to pick on Klement, any parser, that is, callback, and/or, big old node maker, any parser that does not offer key understanding of what data is significant must be essentially re-parsed. For example "cmd":"do this", offers a chunk string "cmd" and a value "do this", which, must be compared against a set of keywords in xmlservice to "understand" i am a CMD, and, you must "do this". Frankly, much faster to have the understanding of "significance" at the same, or, in graphing terms, close, thereby only worry about significant things (_attr, __text, element).

So, more ... original XML design (back in day) ... i tried SAX parser that performs very well, but the callback based node parsing resulted in double look-ups to "understand" what was significant and actionable, resulting in horrible performance.

Nope, XMLSERVICE needs to do it's own thing, because, well, it is essentially a compiler.

from xmlservice.

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

Frankly, you must forgive my terse responses

I prefer terse. Saves time and keeps from meandering.

That is, for speed, when we see a single underscore it means _attr (attribute), when we see a double underscore __text i means data, no underscrore means possible keyword (pgm, sql, cmd, etc.), or, is simply some container of things (aka, myscript, junk).

I didn't realize the convention was based on parsing algorithm speed. Are you writing your own parser? Have you considered using one that already exists (Scott Klement's port of YAJL)

I need to be careful how much I pursue debating the syntax because I do believe performance is higher priority. The obvious hope is only toolkit writers will need to understand the syntax and then every-day-programmers can simply use the toolkit.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

BTW -- please stop bringing up node.js toolkit xmltojson, it does not actually work under complex data types seen in many RPG call applications. I really do not want to get in trouble for saying so publicly, but try it out yourself on PGM/SRVPGM things bigger than hello world (not commands, they are simple).

In any event, nodejs xmltojson is irrelevant side bar, output is not the real issue, true problem is the input side of json, and, understanding quickly how to layout the data to make an actual call.

Note to readers ... don't worry, you do not have a problem with node.js when already working for your applications. That is to say a high percentage of RPG calls are "simple", therefore, will NEVER encounter hash key reduction. Essentially, if your node.js toolkit call works, then it will continue to work. Why? Because your RPG program is compiled, aka, static geometry of parameters, aka, works because it always works.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

No, you are missing the problem. We need the architecture to closely match XML to limit the the significant data to parse. That is, for speed, when we see a single underscore it means _attr (attribute), when we see a double underscore __text means data, no underscore means possible keyword (pgm, sql, cmd, etc.), or, is simply container of things (aka, myscript, junk).

When used in JAVA, JSON is used for things like Objects wherein BOTH client and the server have "pre-defined" structure, aka, "perfect knowledge" about the data content, therefore hydration/dehydration is "perfect". To wit, there is no need for anything like an underscore to establish that this means an _attribute, or __text means the actual data.

Again, in our case, XMLSERVICE must very quickly "understand" what chunk of the json string is data (__text), what is attribute (_type:12p2) , what is action keyword (pgm, cmd, sql, etc.). Without "what am i" knowledge quickly understood, xmlservice must look through all possible keywords under every context ... actually ... i tried this initially ... was 4-5X slower than XML parsing, which make JSON people freak out (burst the comfortable bubble).

Frankly, you must forgive my terse responses, i have been bracing myself for the JSON "art in the park" insanity for years now. I have avoided touching this nerve because so few people can think in terms of generic service, they always use a single example, wherein the brain understands what the XMLSERVICE parsing can not ... argh.

from xmlservice.

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

My "xml to json" example wasn't using the codebeautify tool and instead operating off of what the Node.js itoolkit.js is doing. Per your other post, I haven't taken itoolkit.js to extensive levels of structure, but that fix is a simple matter of getting the structure right.

Here's the full unedited REPL:

% node
> var xt = require("/QOpenSys/QIBM/ProdData/Node/os400/xstoolkit/lib/itoolkit")
undefined
> var conn = new xt.iConn("*LOCAL")
undefined
> conn.add(xt.iCmd('RTVJOBA USER(?)'))
undefined
> conn.run(function(str) {
...   console.log(str)
...   console.log(xt.xmlToJson(str))
... })
<?xml version='1.0'?><myscript><cmd exec='rexx' error='fast'><success>+++ success RTVJOBA USER(?)</success>
<row>
<data desc='USER'>QUSER</data>
</row>
</cmd>
</myscript>
[ { type: 'cmd',
    success: true,
    cmd: 'RTVJOBA USER(?)',
    data: [ [Object] ] } ]
undefined

To wit, i am keeping underscores, because, "beautify" folks really are practising experts with millions of json dancers on the ball room floor using this conversion tool ... cough ... not you or i doing json baby steps on toes.

... and then ...

Like i keep saying ... NO ... we follow the experts here, and, do not try to invent this on our own.

Maybe a better way for me to ask... Where else is this underscore approach used in the rest of the JSON world? When I search I only find Javascript reasonings for underscores as the first character(s). If the goal is to follow the experts then I'd recommend looking at Google (opinion).

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

I wish to avoid confusion, a json "art" running battle is likely to go on until delivery.

For people following this discussion ... until i say different ... If you want to see what XMLSERVICE input JSON will look like, simply cut/paste any current XML document generated by any language 'toolkit' for XMLSERVICE into this tool provided by "code beautify experts".

http://codebeautify.org/xmltojson.

Until the code beautify model fails (not expected) ... or ... i see a very convincing "functional" reason to change, that is, not eye of beholder beauty (irrelevant), above link should generate XMLSERVICE "parse" of the XMLSERVICE JSON support.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

BTW -- not to pick on other authors, but, nodejs example conversion to JSON completely fails on larger datasets. The model they use eventually simply removes hash collision data, aka, they messed up badly. We saw the same thing with first PHP toolkit design, wherein, a special keyword for "data Integrity" was added to keep the hash table reduction throwing out tons of data.

If you do not believe me about node.js, start trying some nested and arrayed DS type structures, and, you will find they will end tossing data as the node.js toolkit converts from XML to json ... (yep, i showed them).

Like i keep saying ... NO ... we follow the experts here, and, do not try to invent this on our own.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Until it fails, i have no intention of straying away from code beautify model. To wit, i am keeping underscores, because, "beautify" folks really are practising experts with millions of json dancers on the ball room floor using this conversion tool ... cough ... not you or i doing json baby steps on toes.

from xmlservice.

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

I INTENTIONALLY did not design the underscore XML matching architecture method, instead left design to JSON professionals. Cough, in fact, cough, design via most arrogant folks about JSON on the web. Jolly souls with audacity to claim domain name "code beautify dot org" http://codebeautify.org/xmltojson.

I fail to see how codebeautify.org peoples are the experts. Instead we should adhere to the specs of json.org for data types and then go about our own structural planning. The json for XMLSERVICE doesn't need to be an exact mirror of the xml (opinion) and instead can be formed according to what those using json would expect. Further, you have to consider that the codebeautify folks did it that way to support going back to xml from json. We don't have that need if we have the "graph" you're introducing.

To further our thoughts we can take a peek at what the Node.js itoolkit.js did with the xmlToJson function. Here's an example:

XML response:

<?xml version='1.0'?>
<myscript>
  <cmd exec='rexx' error='fast'>
    <success>+++ success 
             RTVJOBA USER(?)</success>
    <row>
      <data desc='USER'>QUSER</data>
    </row>
  </cmd>
</myscript>

xmlToJson conversion of above XML:

[{ "type":"cmd",
   "success":true,
   "cmd":"RTVJOBA USER(?)",
   "data":[{ 
     "name":"USER",
     "value":"QUSER"
   }]
}]

new "graphing" technique is essentially an intermediate representation of the input data, aka, a compile artifact,

Thanks for expounding as I didn't understand what you meant but now I do.

If we choose to pursue, this would introduce essentially xmlservice compiler, whereby, only the data would have to be passed on any following call (pattern recalled from database, etc.).

Cool idea. I don't know if database is the storage solution I'd pick and instead maybe store it in the same location of IFS socket descriptor for when "stateful XMLSERVICE" is being accomplished? Because if somebody is looking to cache program structure definition then surely they would already be using persistent XMLSERVICE calls, right? I am thinking out loud and have only started to ponder this caching approach, so take this comment with salt.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

One last thing for geeks (not a promise) ... new "graphing" technique is essentially an intermediate representation of the input data, aka, a compile artifact, in the same design as most scripting languages (java byte code). Therefore, it would appear possible to "save/recall" call geography representation of a PGM. If we choose to pursue, this would introduce essentially xmlservice compiler, whereby, only the data would have to be passed on any following call (pattern recalled from database, etc.).

... but, again ... no promises ... i have a life as well as interest in computer science ... understand???

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Secondary, requiring rules of underscore above, freedom rules, wherein, "input" customer use of JSON hash curly bracket and/or array simple bracket formatting does not seem to affect JSON XMLSERVICE parser (bracket is cute, but irrelevant). That is to say, you may go nuts with JSON input, and, to date, the thing still works, because ultimately only the keywords (elem, _attr, __text) are "graphed".

BTW --- Yep, took me weeks to understand this data anomaly as it applies to "parameter marshalling". Fortunately, this "graphing" insight has also yielded the ability to take either XML/JSON and return either JSON/XML with a simple flip of switch.

My favourite quote for innovation ...

When you are a Bear of Very Little Brain, and you Think of Things, you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. (A.A. Milne, Winnie-the-Pooh )

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

XML is full architecture to assign node elements, attributes, and values. JSON, cough stupid JSON (irreverence is accurate) , requires "convention" architecture and discipline to enable parameter marshalling in a generic sense. That is to say, customer program call formats are never pre-determined, therefore JSON "syntax" must carry "hints" about the intent of the random string of data.

Specifically ...

#!shell

elem -- no underline is an element (pgm, cmd, sh, sql)
_attr -- one underline is an attribute (_type:12P2, _mode=opm, ...)
__text -- two underline is special attribute text/data (__text:42.42, ...)

I intentionally did NOT design the underscore XML matching architecture method, instead left design to JSON professionals. Cough, in fact, cough, design via most arrogant folks about JSON on the web. Jolly souls with audacity to claim domain name "code beautify dot org" http://codebeautify.org/xmltojson.

**Therefore, to see an example of the input of JSON, simply cut/paste any current XMLSERVICE XML representation into the code beautify link (above), no snips needed, just cut/paste away. **

Why Ranger Cairns will not chase hither and yarn, following Aaron or anyone else into JSON "art in the park" discussion???

This says it all ...

We, of course, need a JSONXML XMLSERVICE architecture, or, simple chaos of random desires will lead to entropy.

(Underscore design "code beautify") ... appears to be "parse possible", mixing slight elements of discipline into JSON wild, wild, west (chaos), while allowing reasonable freedom for nesting structures, json beauty, etc.

Dude, dude, dude, i ask myself (and you), are you really going to argue with the best JSON experts on the web??? Really?? Really??? Never, i am a simple geek sheep following "code beautify" greatness of JSON experts with the underscore design.

To date following code beautify, i have achieved 2X performance both XML and JSON for XMLSERVICE. Also, using a new graphing technique, it appears the input can be either JSON or XML and ... best ... best ... best ... it will output either XML or JSON (does not have to match input).

from xmlservice.

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

Couple comments/questions:

Why the underscores? (i.e. _type)

                "data": {
                    "_type": "10i0",
                    "__text": "0"
                }

If underscores are necessary then note the __text one has two underscores.

Need to make sure to support the multi-cmd/pgm/sh/etc. Guessing we'd want to use a JSON array immediately within script.

Before:

{
    "script": {
        "pgm": {

After:

{
    "script": [{
        "pgm": {

Further, this then begs the question of whether we need script at all and instead jump right into a JSON array:

[{
	"pgm": {

Side Note: I don't know how many iterations of json structural proposal changes this will go through, but one option to let everyone know what the current structure looks like is to use Bitbucket snippets which store revisions.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Update.

Good news. Results are initial only, not a promise (word to wise). Simply working XML parser to "make room" for JSON, has doubled the speed of XML parsing, and, made better looking RPG code (everything grows).

Task at hand, parsing Mr. Json. I am attempting to follow this general xml<>json archtecture xmltojson. Appears to be "parse possible", mixing slight elements of discipline into JSON wild, wild, west (chaos), while allowing reasonable freedom for nesting structures, json beauty, etc.

New JSON (just a bit of discipline - xmltojson ):

#!shell

{
    "script": {
        "pgm": {
            "parm": [
                {
                    "data": {
                        "_type": "1A",
                        "_var": "INCHARA",
                        "__text": "a"
                    },
                    "_io": "both"
                },
                {
                    "data": {
                        "_type": "1A",
                        "_var": "INCHARB"
                    },
                    "_io": "both"
                },
                {
                    "data": {
                        "_type": "7p4",
                        "_var": "INDEC1",
                        "__text": "11.1111"
                    },
                    "_io": "both"
                },
                {
                    "data": {
                        "_type": "12p2",
                        "_var": "INDEC2",
                        "__text": "222.22"
                    },
                    "_io": "both"
                },
                {
                    "ds": {
                        "data": [
                            {
                                "_type": "1A",
                                "_var": "INDS1.DSCHARA",
                                "__text": "x"
                            },
                            {
                                "_type": "1A",
                                "_var": "INDS1.DSCHARB",
                                "__text": "y"
                            },
                            {
                                "_type": "7p4",
                                "_var": "INDS1.DSDEC1",
                                "__text": "66.6666"
                            },
                            {
                                "_type": "12p2",
                                "_var": "INDS1.DSDEC2",
                                "__text": "77777.77"
                            }
                        ]
                    },
                    "_io": "both"
                }
            ],
            "return": {
                "data": {
                    "_type": "10i0",
                    "__text": "0"
                }
            },
            "_name": "ZZCALL",
            "_lib": "xyzlibxmlservicexyz"
        }
    }
}

Old XML (complete architecture - XMLSERVICE toolkit writers ):

#!shell

<?xml version='1.0'?>
<script>
<pgm name='ZZCALL' lib='xyzlibxmlservicexyz'>
 <parm  io='both'>
   <data type='1A' var='INCHARA'>a</data>
 </parm>
 <parm  io='both'>
   <data type='1A' var='INCHARB'/>
 </parm>
 <parm  io='both'>
   <data type='7p4' var='INDEC1'>11.1111</data>
 </parm>
 <parm  io='both'>
   <data type='12p2' var='INDEC2'>222.22</data>
 </parm>
 <parm  io='both'>
  <ds>
   <data type='1A' var='INDS1.DSCHARA'>x</data>
   <data type='1A' var='INDS1.DSCHARB'>y</data>
   <data type='7p4' var='INDS1.DSDEC1'>66.6666</data>
   <data type='12p2' var='INDS1.DSDEC2'>77777.77</data>
  </ds>
 </parm>
 <return>
  <data type='10i0'>0</data>
 </return>
</pgm>
</script>

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

You may want to wait on JSON parser work. Looking at the XML parser, works, but could use a face lift (different algorithm).

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

BTW -- I agree 'another communication' is a wonderful idea. XMLSERVICE json could be good, but i am trying to set expectations for performance similar to XML. Although we will redo all the parsing and very likely perform better.

Truth, fashion, has always baffled the geek in me. Anyway, modern languages actually provided 'very fast' parsers for 'popular' JSON. Aka, popularity, or fashion, can be a good thing, result in actual geeks doing something (like me). After all, i don't want to be monster XML-a-stien hunted by json-village crowd with pitch forks and fire sticks (Halloween reference).

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

No problem. In fact, regardless of "parser", we will still need a JSON architecture protocol that covers all the XMLSERVICE capabilities as listed for XML xml for toolkit writers. You could help with that, preferably in RPG, therein, can probably use in the new xmlservice version (forgive my JSON syntax, i have little practice) ...

#!python
      * ---
      * <cmd [exec='cmd|system|rexx'
      *       hex='on' 
      *       before='cc1/cc2/cc3/cc4'
      *       after='cc4/cc3/cc2/cc1'
      *       error='on|off|fast'
      *       ]>values (see IBM i *CMD)</cmd>
      * ---


{operation:cmd,
 options:{exec:'cmd|system|rexx', hex:'on',before:'cc1/cc2/cc3/cc4',after:'cc4/cc3/cc2/cc1':error:'on|off|fast'},
 value:'CHGLIBL yada yada'
}

      * ---
      * <sh [rows='on|off' 
      *      hex='on'
      *      before='cc1/cc2/cc3/cc4'
      *      after='cc4/cc3/cc2/cc1' 
      *      error='on|off|fast'                                       
      *      ]>values (see PASE utility)</sh>
      * ---

{operation:sh,
 options: {rows:'on|off', hex:'on',before:'cc1/cc2/cc3/cc4',after:'cc4/cc3/cc2/cc1':error:'on|off|fast'},
 value:'ps -ef'
}

====
... so on (remember RPG recursive, so can nest, etc., see plugxml.rpgle) ...
====

:  ... see the link, this list is too long ... :

from xmlservice.

Original comment by Luca Zovi (Bitbucket: luca_zovi, GitHub: lucazovi).

Hey hey, I don't want to hurt anyone. JSON is the actual fashion, XML the fashion in the past, tommorrow I don't know. I think it's not a performance problem but to give another comunication solution. I can develope in RPG, C++ , PHP, If you have some ideas, I can try it for you. Bye

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Addendum for consideration (aka, i will not lose the thought). Brief, 'perfect data geometry pre-knowledge' exists, therein, adventurous RPG developer, could in fact write your own 'perfect parser' and/or use your own library parser (Klement yajl).

#!shell

<pgm name='mypgm' lib='mylib'>
DIY -- everything in here give to mypgm, 'perfect parser', anything string form
</pgm>

     C     *Entry        PLIST                   
     C                   PARM                    a_big_string_inout_via_xmlservice

btw -- english idom DIY, stands for Do It Yourself, fitting keyword for taking over XMLSERVICE work, and, well, doing it yourself.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

BTW -- i have heard a JSON performance fantasy story far too many times. Most often, someone builds a 'demo', wherein, the client and the server have "perfect data geometry pre-knowledge", and,of course this will run faster than XMLSERVICE the "generic call anything" protocol. Not helpful to compare of "apples" and "oranges".

However, when "screaming fast" is required, may be best to write a custom 'exact match' protocol (aka, Do It Yourself). In fact, the very fastest call is to write a PASE c code extension to any scripting language: pecl for PHP, gem for Ruby, egg for python, etc.

You are a smart guy, a contributor to XMLSERVICE, thanks. I will try to post a JSONXML architecture to yips at some point so we can disscuss the merits of 'generic xmlservice format'.

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Generic JSON, absolutely not. We, of course, need a JSONXML XMLSERVICE architecture, or, simple chaos of random desires will lead to entropy. Generic JSON would never work, XMLSERVICE would be lost completely, this is obvious.

Unfortunately many people have big delusion associated with JSON excitement. Essentially XMLSERVICE is a compiler, where in the "user" feeds XML (or JSON), which is just a big string, that needs to be 'marshalled' into real nested data structures with real values and real pointers, then, load/activates a *PGM/*SRVPGM (other), and calls, followed by a reverse of process back into string again (out pops XML/JSON). VERY likely going to find that 'real work' XMLSERVICE performance difference between XML (a string), and, JSON (a string), is "the same". O

from xmlservice.

Original comment by Luca Zovi (Bitbucket: luca_zovi, GitHub: lucazovi).

xmlservice should create / work with a generic input/output object (not possible I think with RPG) and then any extension should create their own input / output wrapper (XML, JSON, etc.)

from xmlservice.

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

Cool. Not many details, so i cannot answer your question, nor, can i say which IBM i JSON parser would be best.

Task one goal is to architect a general purpose IBM i 'call' JSON protocol, similar to XML for 'everything' (*PGM, *SRVPGM, PASE, DB2, etc.). That is to say, JSON 'go fast' will be worthless if you can't call everything XMLSERVICE is already supporting. Fortuitously, JSON mission, aka, multiple source in/out both XML / JSON, also offers a 'reason' redo many things costing performance in XML parsing.

However, speculating without supporting data (talk at water cooler), very possible highest performing solutions/parsers will be best of breed using hybrid PASE-2-RPG in-process techniques, aka, PASE c code extensions to languages python, ruby, php, nodejs, etc. So ... probably a bit early to pick a winner in IBM i for JSON parsing, yes???

from xmlservice.