How about deprecate —file and replace with —path? In the transition make them mutually exclusive and —path required for —parallel.
Any reason to not just make all export parallel rather than supporting two different modes? -Jake Sent from my iPhone > On Aug 22, 2017, at 12:27 PM, Kenneth Howe <kh...@pivotal.io> wrote: > > I agrees that overloading the “file” option seems like a bad idea. As an > alternative to separate commands, what about mutually exclusive options, > ‘—file’ and ‘—dir’? > > If you go for implementing the new functionality as a separate command, I > would suggest calling the gfsh commands: “export data-parallel” and “import > data-parallel" > >> On Aug 22, 2017, at 11:32 AM, Nick Reich <nre...@pivotal.io> wrote: >> >> Team, >> >> I am working on exposing the parallel export/import of snapshots through >> gfsh and would appreciate input on the best approach to adding to / >> updating the existing interface. >> >> Currently, ExportDataCommand and ImportDataCommand take a region name, a >> member to run the command on, and a file location (that must end in .gfd). >> Parallel import and export require a directory location instead of a single >> file name (as there can be multiple files and need for uniquely named >> files). It is possible to add a parallel flag and have the meaning of the >> "file" parameter be different depending on that flag, but that seems overly >> confusing to me. I am instead leaning towards creating new commands (e.g. >> ParallelExportDataCommand) that has a "directory" parameter to replace >> "file", but is otherwise identical in usage to the existing commands. >> >> Do others have different views or approaches to suggest? >
