Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-27 Thread Aleksandr Pakhomov
Roman, 

Thank you, that makes sense. 

> On 27 May 2022, at 14:26, Roman Puchkovskiy  
> wrote:
> 
> Aleksandr,
> 
> The thing is that `cluster init` is not just for setting some kind of
> a configuration, it's more about doing cluster initialization
> described in [1]. This init process transitions the cluster from
> 'empty' state to 'initialized state'; this can be only made once per
> cluster, and it has to be done for the cluster to function.
> 
> So I'd suggest to remove the mentioning of 'configuration' at all;
> also, `--cluster-url` and `--configuration-file` are not the
> parameters that are currently implemented; it's actually (currently)
> taking `--node-endpoint`, `--meta-storage-node` (1+ occurrences) and
> `--cmg-node` (0+ occurrences) parameters.
> 
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization
> 
> пт, 27 мая 2022 г. в 13:04, Aleksandr Pakhomov :
>> 
>> Hi Roman,
>> 
>> That is a good point. In the proposal I mean
>> the analogue for existing ‘cluster init’. Maybe
>> “distributed configuration” confuses you and
>> probably I have to name it like “meta-storage”
>> configuration or something like this.
>> 
>> As for 'ignite init’  I think it would be more clearer
>> if we rename it to ‘ignite install’ and there won’t
>> any confusion at all.
>> 
>> What do you think?
>> 
>>> On 27 May 2022, at 10:20, Roman Puchkovskiy  
>>> wrote:
>>> 
>>> Hi Aleksandr.
>>> 
>>> There is a command named 'init' in your proposal. According to its
>>> description, it initializes the cluster with a distributed
>>> configuration. I'm not sure how it's mapped to the existing commands.
>>> The thing is that currently, there is `ignite init` command that
>>> initializes (actually, installs) Ignite on the current machine (its
>>> description does not mention distributed configuration), and there is
>>> also `ignite cluster init` that initializes the cluster (see [1], for
>>> example), which does not concern distributed configuration as well.
>>> 
>>> So it looks like the 2 existing commands got dropped and replaced with
>>> another 'init' command relating to the distributed config.
>>> 
>>> Was it intentional?
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-14871
>>> 
>>> ср, 25 мая 2022 г. в 18:12, Andrey Gura :
 
 Aleksandr,
 
 Both proposed options look good to me because both cases assume that a
 user must express their intent explicitly.
 
 On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  
 wrote:
> 
> I got it. What do you think about this proposal:
> 
> -  “ignite”  prints help
> -  “ignite shell” enters REPL
> 
> Or
> 
> -  “ignite” prints help
> -  “ignite-shell” enters REPL and it is a separate application
> 
> I prefer the first varian but I would like to hear opinions of other 
> community members.
> 
> 
>> On 19 May 2022, at 01:16, Andrey Gura  wrote:
>> 
>> I can just have a mistake in my script, e.g. running ignite command
>> without any parameters. What will happen in such a case from the
>> script perspective? I think the script will wait for returning value
>> while the shell will wait for a user input. Due to a server-side
>> nature of the script it will hang forever because there is no user on
>> the server side.
> 
>> 



Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-27 Thread Roman Puchkovskiy
Aleksandr,

The thing is that `cluster init` is not just for setting some kind of
a configuration, it's more about doing cluster initialization
described in [1]. This init process transitions the cluster from
'empty' state to 'initialized state'; this can be only made once per
cluster, and it has to be done for the cluster to function.

So I'd suggest to remove the mentioning of 'configuration' at all;
also, `--cluster-url` and `--configuration-file` are not the
parameters that are currently implemented; it's actually (currently)
taking `--node-endpoint`, `--meta-storage-node` (1+ occurrences) and
`--cmg-node` (0+ occurrences) parameters.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization

пт, 27 мая 2022 г. в 13:04, Aleksandr Pakhomov :
>
> Hi Roman,
>
> That is a good point. In the proposal I mean
> the analogue for existing ‘cluster init’. Maybe
> “distributed configuration” confuses you and
> probably I have to name it like “meta-storage”
> configuration or something like this.
>
> As for 'ignite init’  I think it would be more clearer
> if we rename it to ‘ignite install’ and there won’t
> any confusion at all.
>
> What do you think?
>
> > On 27 May 2022, at 10:20, Roman Puchkovskiy  
> > wrote:
> >
> > Hi Aleksandr.
> >
> > There is a command named 'init' in your proposal. According to its
> > description, it initializes the cluster with a distributed
> > configuration. I'm not sure how it's mapped to the existing commands.
> > The thing is that currently, there is `ignite init` command that
> > initializes (actually, installs) Ignite on the current machine (its
> > description does not mention distributed configuration), and there is
> > also `ignite cluster init` that initializes the cluster (see [1], for
> > example), which does not concern distributed configuration as well.
> >
> > So it looks like the 2 existing commands got dropped and replaced with
> > another 'init' command relating to the distributed config.
> >
> > Was it intentional?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-14871
> >
> > ср, 25 мая 2022 г. в 18:12, Andrey Gura :
> >>
> >> Aleksandr,
> >>
> >> Both proposed options look good to me because both cases assume that a
> >> user must express their intent explicitly.
> >>
> >> On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  
> >> wrote:
> >>>
> >>> I got it. What do you think about this proposal:
> >>>
> >>> -  “ignite”  prints help
> >>> -  “ignite shell” enters REPL
> >>>
> >>> Or
> >>>
> >>> -  “ignite” prints help
> >>> -  “ignite-shell” enters REPL and it is a separate application
> >>>
> >>> I prefer the first varian but I would like to hear opinions of other 
> >>> community members.
> >>>
> >>>
>  On 19 May 2022, at 01:16, Andrey Gura  wrote:
> 
>  I can just have a mistake in my script, e.g. running ignite command
>  without any parameters. What will happen in such a case from the
>  script perspective? I think the script will wait for returning value
>  while the shell will wait for a user input. Due to a server-side
>  nature of the script it will hang forever because there is no user on
>  the server side.
> >>>
>


Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-27 Thread Aleksandr Pakhomov
Hi Roman, 

That is a good point. In the proposal I mean 
the analogue for existing ‘cluster init’. Maybe 
“distributed configuration” confuses you and
probably I have to name it like “meta-storage”
configuration or something like this.

As for 'ignite init’  I think it would be more clearer
if we rename it to ‘ignite install’ and there won’t 
any confusion at all. 

What do you think?

> On 27 May 2022, at 10:20, Roman Puchkovskiy  
> wrote:
> 
> Hi Aleksandr.
> 
> There is a command named 'init' in your proposal. According to its
> description, it initializes the cluster with a distributed
> configuration. I'm not sure how it's mapped to the existing commands.
> The thing is that currently, there is `ignite init` command that
> initializes (actually, installs) Ignite on the current machine (its
> description does not mention distributed configuration), and there is
> also `ignite cluster init` that initializes the cluster (see [1], for
> example), which does not concern distributed configuration as well.
> 
> So it looks like the 2 existing commands got dropped and replaced with
> another 'init' command relating to the distributed config.
> 
> Was it intentional?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-14871
> 
> ср, 25 мая 2022 г. в 18:12, Andrey Gura :
>> 
>> Aleksandr,
>> 
>> Both proposed options look good to me because both cases assume that a
>> user must express their intent explicitly.
>> 
>> On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  wrote:
>>> 
>>> I got it. What do you think about this proposal:
>>> 
>>> -  “ignite”  prints help
>>> -  “ignite shell” enters REPL
>>> 
>>> Or
>>> 
>>> -  “ignite” prints help
>>> -  “ignite-shell” enters REPL and it is a separate application
>>> 
>>> I prefer the first varian but I would like to hear opinions of other 
>>> community members.
>>> 
>>> 
 On 19 May 2022, at 01:16, Andrey Gura  wrote:
 
 I can just have a mistake in my script, e.g. running ignite command
 without any parameters. What will happen in such a case from the
 script perspective? I think the script will wait for returning value
 while the shell will wait for a user input. Due to a server-side
 nature of the script it will hang forever because there is no user on
 the server side.
>>> 



Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-27 Thread Roman Puchkovskiy
Hi Aleksandr.

There is a command named 'init' in your proposal. According to its
description, it initializes the cluster with a distributed
configuration. I'm not sure how it's mapped to the existing commands.
The thing is that currently, there is `ignite init` command that
initializes (actually, installs) Ignite on the current machine (its
description does not mention distributed configuration), and there is
also `ignite cluster init` that initializes the cluster (see [1], for
example), which does not concern distributed configuration as well.

So it looks like the 2 existing commands got dropped and replaced with
another 'init' command relating to the distributed config.

Was it intentional?

[1] https://issues.apache.org/jira/browse/IGNITE-14871

ср, 25 мая 2022 г. в 18:12, Andrey Gura :
>
> Aleksandr,
>
> Both proposed options look good to me because both cases assume that a
> user must express their intent explicitly.
>
> On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  wrote:
> >
> > I got it. What do you think about this proposal:
> >
> > -  “ignite”  prints help
> > -  “ignite shell” enters REPL
> >
> > Or
> >
> > -  “ignite” prints help
> > -  “ignite-shell” enters REPL and it is a separate application
> >
> > I prefer the first varian but I would like to hear opinions of other 
> > community members.
> >
> >
> > > On 19 May 2022, at 01:16, Andrey Gura  wrote:
> > >
> > > I can just have a mistake in my script, e.g. running ignite command
> > > without any parameters. What will happen in such a case from the
> > > script perspective? I think the script will wait for returning value
> > > while the shell will wait for a user input. Due to a server-side
> > > nature of the script it will hang forever because there is no user on
> > > the server side.
> >


Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-25 Thread Andrey Gura
Aleksandr,

Both proposed options look good to me because both cases assume that a
user must express their intent explicitly.

On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  wrote:
>
> I got it. What do you think about this proposal:
>
> -  “ignite”  prints help
> -  “ignite shell” enters REPL
>
> Or
>
> -  “ignite” prints help
> -  “ignite-shell” enters REPL and it is a separate application
>
> I prefer the first varian but I would like to hear opinions of other 
> community members.
>
>
> > On 19 May 2022, at 01:16, Andrey Gura  wrote:
> >
> > I can just have a mistake in my script, e.g. running ignite command
> > without any parameters. What will happen in such a case from the
> > script perspective? I think the script will wait for returning value
> > while the shell will wait for a user input. Due to a server-side
> > nature of the script it will hang forever because there is no user on
> > the server side.
>


Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-20 Thread Aleksandr Pakhomov
Hi Ilya,

Thanks for the python usage example.

AWS cli does not support interactive mode at all. 
Google too. Even Google Big query cli [1] executes
sql queries without interactive shell. 

For REPL-first tools like Reql [2], ksqlDB CLI [3], or 
SnowSQL [4] it is common thing to enter the REPL 
if command was executed without any arguments. 

CLIs that do not support the REPL (or REPL is not
the main value of those tools) tend to print help on 
empty arguments. 



[1] https://cloud.google.com/bigquery/docs/bq-command-line-tool 

[2] https://github.com/Workshape/reql-cli 
 
[3] 
https://docs.ksqldb.io/en/latest/operate-and-deploy/installation/cli-config/ 

[4] https://docs.snowflake.com/en/user-guide/snowsql-use.html 
 

> On 19 May 2022, at 11:44, Ilya Korol  wrote:
> 
> From my perspective we should move towards existing UX approaches. For 
> example:
> python - enters shell
> python --help  - prints help
> python -c - executes command
> 
> What about other CLI tools that works with remote services? I can't remember 
> properly but do AWS, openshift or maybe GCP CLIs also supports shell mode? If 
> so, how it is organized?
> 
> 19.05.2022 17:53, Aleksandr Pakhomov пишет:
>> I got it. What do you think about this proposal:
>> 
>> -  “ignite”  prints help
>> -  “ignite shell” enters REPL
>> 
>> Or
>> 
>> -  “ignite” prints help
>> -  “ignite-shell” enters REPL and it is a separate application
>> 
>> I prefer the first varian but I would like to hear opinions of other 
>> community members.
>> 
>> 
>>> On 19 May 2022, at 01:16, Andrey Gura  wrote:
>>> 
>>> I can just have a mistake in my script, e.g. running ignite command
>>> without any parameters. What will happen in such a case from the
>>> script perspective? I think the script will wait for returning value
>>> while the shell will wait for a user input. Due to a server-side
>>> nature of the script it will hang forever because there is no user on
>>> the server side.
>> 



Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-19 Thread Ilya Korol
From my perspective we should move towards existing UX approaches. For 
example:

python - enters shell
python --help  - prints help
python -c - executes command

What about other CLI tools that works with remote services? I can't 
remember properly but do AWS, openshift or maybe GCP CLIs also supports 
shell mode? If so, how it is organized?


19.05.2022 17:53, Aleksandr Pakhomov пишет:

I got it. What do you think about this proposal:

-  “ignite”  prints help
-  “ignite shell” enters REPL

Or

-  “ignite” prints help
-  “ignite-shell” enters REPL and it is a separate application

I prefer the first varian but I would like to hear opinions of other community 
members.



On 19 May 2022, at 01:16, Andrey Gura  wrote:

I can just have a mistake in my script, e.g. running ignite command
without any parameters. What will happen in such a case from the
script perspective? I think the script will wait for returning value
while the shell will wait for a user input. Due to a server-side
nature of the script it will hang forever because there is no user on
the server side.




Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-19 Thread Aleksandr Pakhomov
I got it. What do you think about this proposal:

-  “ignite”  prints help 
-  “ignite shell” enters REPL

Or

-  “ignite” prints help 
-  “ignite-shell” enters REPL and it is a separate application

I prefer the first varian but I would like to hear opinions of other community 
members.


> On 19 May 2022, at 01:16, Andrey Gura  wrote:
> 
> I can just have a mistake in my script, e.g. running ignite command
> without any parameters. What will happen in such a case from the
> script perspective? I think the script will wait for returning value
> while the shell will wait for a user input. Due to a server-side
> nature of the script it will hang forever because there is no user on
> the server side.



Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-18 Thread Andrey Gura
> 1. Does “Ignite shell” sounds better?

I don't know. It could be Ignite REPL, IGnite Shell or something else.
Just an idea.

> But I did not get your point about scripting. What do you mean by saying “it 
> will just hang”?  What kind of error is going to be the cause of such 
> behaviour?

I can just have a mistake in my script, e.g. running ignite command
without any parameters. What will happen in such a case from the
script perspective? I think the script will wait for returning value
while the shell will wait for a user input. Due to a server-side
nature of the script it will hang forever because there is no user on
the server side.

On Thu, May 19, 2022 at 1:02 AM Aleksandr Pakhomov  wrote:
>
> Hi, Andrey
>
> Thanks for comments.
>
> 1. Does “Ignite shell” sounds better?
>
> 2. Yes, you are right. Most tools print help if they are executed without 
>   arguments. But I did not get your point about scripting. What do you mean 
> by saying “it will just hang”?  What kind of error is going to be the cause 
> of such behaviour?
>
> > On 18 May 2022, at 21:14, Andrey Gura  wrote:
> >
> > Hi,
> >
> > My two cents:
> >
> > 1. CLI Tool - looks like not the best name :) Shell?
> >
> > 2. The description says: "REPL mode is used by default and is
> > activated if the ignite command is executed without parameters."
> >
> > I think it is a bad idea. Firstly, it is usual CLI's behaviour to
> > print a help for a user. An exception if we would use a special CLI
> > for REPL. Shell? :)
> > Also such approach breaks my expectations related to a scripting. In
> > case of an error in a script it will just hang. So, a separate CLI
> > utility looks better than ignite CLI.
> >
> >
> > On Thu, May 12, 2022 at 11:43 PM Aleksandr Pakhomov  
> > wrote:
> >>
> >> Hello, Igniters.
> >>
> >> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The 
> >> main value is to develop a user-friendly command-line tool with advanced 
> >> completions and SQL REPL mode.
> >>
> >> The set of commands and parameters can be discussed. Questions and 
> >> comments are welcomed.
> >>
> >> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
> >> 
>


Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-18 Thread Aleksandr Pakhomov
Hi, Andrey

Thanks for comments.

1. Does “Ignite shell” sounds better? 

2. Yes, you are right. Most tools print help if they are executed without   
arguments. But I did not get your point about scripting. What do you mean by 
saying “it will just hang”?  What kind of error is going to be the cause of 
such behaviour?

> On 18 May 2022, at 21:14, Andrey Gura  wrote:
> 
> Hi,
> 
> My two cents:
> 
> 1. CLI Tool - looks like not the best name :) Shell?
> 
> 2. The description says: "REPL mode is used by default and is
> activated if the ignite command is executed without parameters."
> 
> I think it is a bad idea. Firstly, it is usual CLI's behaviour to
> print a help for a user. An exception if we would use a special CLI
> for REPL. Shell? :)
> Also such approach breaks my expectations related to a scripting. In
> case of an error in a script it will just hang. So, a separate CLI
> utility looks better than ignite CLI.
> 
> 
> On Thu, May 12, 2022 at 11:43 PM Aleksandr Pakhomov  wrote:
>> 
>> Hello, Igniters.
>> 
>> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The 
>> main value is to develop a user-friendly command-line tool with advanced 
>> completions and SQL REPL mode.
>> 
>> The set of commands and parameters can be discussed. Questions and comments 
>> are welcomed.
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
>> 



Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-18 Thread Andrey Gura
Hi,

My two cents:

1. CLI Tool - looks like not the best name :) Shell?

2. The description says: "REPL mode is used by default and is
activated if the ignite command is executed without parameters."

I think it is a bad idea. Firstly, it is usual CLI's behaviour to
print a help for a user. An exception if we would use a special CLI
for REPL. Shell? :)
Also such approach breaks my expectations related to a scripting. In
case of an error in a script it will just hang. So, a separate CLI
utility looks better than ignite CLI.


On Thu, May 12, 2022 at 11:43 PM Aleksandr Pakhomov  wrote:
>
> Hello, Igniters.
>
> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The main 
> value is to develop a user-friendly command-line tool with advanced 
> completions and SQL REPL mode.
>
> The set of commands and parameters can be discussed. Questions and comments 
> are welcomed.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
> 


Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-13 Thread Aleksandr Pakhomov
Hi Misha.

Thank you for your valid points.

I accept your suggestion about "ignite cli config get/set" naming.
As for default commands, I think "clear" and "exit" are only for REPL mode and 
I'll add them to the description of the commands. "ignite help" is already 
defined there.

> On 13 May 2022, at 17:04, Mikhail Pochatkin  wrote:
> 
> Hello, Sasha.
> 
> The description looks good to me, only a few comments.
> 
> 1. I would suggest renaming the CLI configuration command. Currently
> "ignite default get" and "ignite default set" look not informative. I
> understand that "ignite config" is already used for the Ignite
> configuration command and this is a problem to find another good name for
> this command. My suggestion is "ignite cli config", if anyone has a better
> variant, you are welcome.
> 2. I think that Ignite CLI should also have default commands like "ignite
> help", "ignite clear", "ignite exit" and etc. Could you please add topics
> about these commands.
> 
> On Thu, May 12, 2022 at 11:43 PM Aleksandr Pakhomov 
> wrote:
> 
>> Hello, Igniters.
>> 
>> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The
>> main value is to develop a user-friendly command-line tool with advanced
>> completions and SQL REPL mode.
>> 
>> The set of commands and parameters can be discussed. Questions and
>> comments are welcomed.
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool
>> 



Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-13 Thread Aleksandr Pakhomov
Hi Maxim. 

Thank you for your comments.

- Yes, the non-interactive mode is supported for all commands except "connect", 
"disconnect", "status".

- Benefits of using REST as a communication realization between CLI and Ignite 
3 cluster:
  1) This approach seems to be the de-facto standard for the client-server 
communication 
  2) CLI can connect to any cluster it has a network connection 
  3) REST component already implemented in Ignite 3
  4) REST client can be generated from Open API specification (see IEP-87 
).
  5) REST is languege-agnostic, so web ui or third party software can consume 
an API spec provided by the server.

- Drawbacks of using REST: additional client and server libraries have to be 
included to the CLI and Ignite distributions.

As for alternatives, I would mention that the custom sdk could be an option. 
But it requires a lot of afford to design and develop and can be used only by 
Java clients. 

- Yes, the command autocomplition provided out of the box. I've added an 
information about this.

I'll add a brief overview of popular CLIs to the IEP.


> On 13 May 2022, at 15:05, Maxim Muzafarov  wrote:
> 
> Hello Aleksanrd,
> 
> 
> The description looks good. A few questions below:
> 
> - Can the CLI also be run in non-interactive mode to support scripts
> execution (like the WildFly it does [1])? Will it be possible though
> the REST it used?
> - What is the benefits and drawbacks of using REST for this tool? Are
> there any alternative for that?
> - Would we have command autocomplition out of the box? It doesn't
> mentioned, but seems to be a very user friendly ability.
> 
> Can you provide a briefly comparison for such a CLI tools for other
> databases and/or systems, application servers? It seems the developing
> CLI tool is a common task, so I think at least we should mention about
> the common development approach in modern systems for such tools. For
> instance, I'm very excited with the wildfly-cli tool usage, however,
> may be it has some drawbacks too.
> 
> [1] https://kb.novaordis.com/index.php/WildFly_CLI_Scripting
> 
> On Thu, 12 May 2022 at 23:43, Aleksandr Pakhomov  wrote:
>> 
>> Hello, Igniters.
>> 
>> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The 
>> main value is to develop a user-friendly command-line tool with advanced 
>> completions and SQL REPL mode.
>> 
>> The set of commands and parameters can be discussed. Questions and comments 
>> are welcomed.
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
>> 



Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-13 Thread Mikhail Pochatkin
Hello, Sasha.

The description looks good to me, only a few comments.

1. I would suggest renaming the CLI configuration command. Currently
"ignite default get" and "ignite default set" look not informative. I
understand that "ignite config" is already used for the Ignite
configuration command and this is a problem to find another good name for
this command. My suggestion is "ignite cli config", if anyone has a better
variant, you are welcome.
2. I think that Ignite CLI should also have default commands like "ignite
help", "ignite clear", "ignite exit" and etc. Could you please add topics
about these commands.

On Thu, May 12, 2022 at 11:43 PM Aleksandr Pakhomov 
wrote:

> Hello, Igniters.
>
> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The
> main value is to develop a user-friendly command-line tool with advanced
> completions and SQL REPL mode.
>
> The set of commands and parameters can be discussed. Questions and
> comments are welcomed.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool
> 


Re: [DISCUSSION] IEP-88: CLI Tool

2022-05-13 Thread Maxim Muzafarov
Hello Aleksanrd,


The description looks good. A few questions below:

- Can the CLI also be run in non-interactive mode to support scripts
execution (like the WildFly it does [1])? Will it be possible though
the REST it used?
- What is the benefits and drawbacks of using REST for this tool? Are
there any alternative for that?
- Would we have command autocomplition out of the box? It doesn't
mentioned, but seems to be a very user friendly ability.

Can you provide a briefly comparison for such a CLI tools for other
databases and/or systems, application servers? It seems the developing
CLI tool is a common task, so I think at least we should mention about
the common development approach in modern systems for such tools. For
instance, I'm very excited with the wildfly-cli tool usage, however,
may be it has some drawbacks too.

[1] https://kb.novaordis.com/index.php/WildFly_CLI_Scripting

On Thu, 12 May 2022 at 23:43, Aleksandr Pakhomov  wrote:
>
> Hello, Igniters.
>
> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The main 
> value is to develop a user-friendly command-line tool with advanced 
> completions and SQL REPL mode.
>
> The set of commands and parameters can be discussed. Questions and comments 
> are welcomed.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
>