Reading over the docs for gfsh - I don't support removing any functionality from a top level command perspective. It should be noted that I didn't go deeper then the top level commands, there might be some sub option on some command that could be dropped or tweaked.
Charlie On Mon, Dec 9, 2019 at 8:32 AM Alexander Murmann <amurm...@pivotal.io> wrote: > > I imagine once the Management v2 API's are GA (and feature complete), I > don't see a reason why /gfsh/ should not be a stand alone module. It > would definitely have to be updated to use the new v2 API's, which > should not have any direct dependency on geode-core any more. > > There also is a big question here of how much of the current GFSH > functionality needs to be there to fully replace the current GFSH. Looking > at the functionality available right now, it seems like we have a very long > way ahead of us. > > On Fri, Dec 6, 2019 at 12:32 PM Owen Nichols <onich...@pivotal.io> wrote: > > > Any standalone management API or client thereof would not be able to > start > > locator or start server. For that gfsh still needs a large chunk of > > Geode. > > > > > > > On Dec 6, 2019, at 12:25 PM, Udo Kohlmeyer <u...@apache.com> wrote: > > > > > > I imagine once the Management v2 API's are GA (and feature complete), I > > don't see a reason why /gfsh/ should not be a stand alone module. It > would > > definitely have to be updated to use the new v2 API's, which should not > > have any direct dependency on geode-core any more. > > > > > > On 12/6/19 10:01 AM, Jacob Barrett wrote: > > >> > > >>> On Dec 6, 2019, at 9:44 AM, Jens Deppe <jde...@pivotal.io> wrote: > > >>> > > >>> Just to be clear, this effort does *not* result in a standalone gfsh > > >>> executable/jar. > > >> Is this a future plan? > > >> > > >> > > > > > -- Charlie Black | cbl...@pivotal.io
