I was under the impression that gfsh console output was intended as a more "active" interface with an operator. To that end, improved usability and a more consistent output sounds like a boon to me.
On Tue, May 1, 2018 at 3:41 PM, Jens Deppe <jensde...@apache.org> wrote: > Hi All, > > I'm working on removing our dependency on geode-json (org.json) in favor of > Jackson. Initially this work has revolved around refactoring the internal > results from gfsh commands (nothing that is user-visible). > > I'm now looking at the various gfsh 'data' commands (get, put, query and > locate) and would very much like them to produce more meaningful, (actual > JSON), structured results. > > For example, a get on a region containing a simple 'User' object produces > this output. > > Result : true > Key Class : java.lang.String > Key : jondoe > Value Class : > org.apache.geode.management.internal.cli.commands. > GetCommandIntegrationTest.User > > This is not very helpful and only really shows that the value, for the > given key, actually exists. > > Querying a PDX object is more informative: > > Result : true > Key Class : java.lang.String > Key : jondoe > Value Class : org.apache.geode.pdx.internal.PdxInstanceImpl > > username | hashcode > -------- | -------- > jondoe | 38de41a9 > > This brings me to the actual question. Although our Java API is backwards > compatible, the gfsh output has never been considered an 'API' in terms of > the structure of it's output text. However, I do want to ask that if we > start making changes to these commands, to produce actual JSON results, > will that cause anyone any pain? > > Thoughts / comments? > > --Jens >
