That would be a really good implementation since it would keep production code from relying on the formatting of the GFSH return message. If you did —output=json, then the call to the GfshParser could possibly involve non-internal classes, which would be even nicer.
> On Nov 4, 2016, at 4:31 PM, Anthony Baker <aba...@pivotal.io> wrote: > > Wes, I think it would be interesting if we added a new option ‘--output=json’ > to better handle the use case you described. Then you could pipe the gfsh > command through a json parser like jq. > > Anthony > >> On Nov 4, 2016, at 9:51 AM, Real Wes <thereal...@outlook.com> wrote: >> >> I call the GFSH Parser from code and rely on the formatting of the return >> message to determine the response. So I’d like to see that code as >> encapsulated in one place. >> >>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao <jil...@pivotal.io> wrote: >>> >>> >>> We have several jira issues related to gfsh parsing (GEODE-1598, >>> GEODE-1912). After spending some time understanding how the parsing works, >>> I found out we have three components intertwined together all trying to do >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by >>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The >>> outcome is I am able to maintain the current parsing and tabbing completion >>> capabilities (and fix a few bugs) by removing 40+ files. The only >>> difference I see so far lies in the help and hint messages. It seems the >>> main reason we are using these home backed Gfsh parsing is to provide more >>> readable help messages. Below are the differences: >>> >>> Using Spring Shell's provided help: >>> >>> Using Gfsh Parsing with JoptSimple: >>> >>> >>> I do like the outcome of the latter, but added complexity of the code is >>> too expensive to bear. So I am asking the community how important it is to >>> maintain the current style of help? Can we do with the cheaper way by just >>> using whatever provided by the libraries? >>> >>> Cheers >>> >>> Jinmei >>> >> >
