You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Trejkaz <tr...@trypticon.org> on 2008/12/31 13:02:01 UTC
The Command API (Felix Shell)
The Command API is currently...
public void execute(String command, PrintStream out, PrintStream err)
After having written a few commands, I find myself doing two things a lot.
Firstly, I find myself parsing command-lines.
Currently all my parameters are whitespace-free but that's about to
change. So now I need a full parser which handles quotes in a
sensible fashion consistent with my other commands, and indeed Felix's
existing commands.
It seems like the ultimate solution to this part would have been to
pass the command as a String[] instead of the raw command. Obviously
I can write my own convenience API for this, but I started wondering
if Felix is already hiding something like this..?
Secondly, I find myself wondering how to handle sub-commands. And
this is where the mail gets big. Sorry about that. for tl;dr types,
scroll down to my proposed interfaces and points below those.
Effectively having solved the parser problem already (which I haven't
solved correctly actually, but for the sake of discussion - the real
code splits on \s+) I now find myself implementing my own sub-command
framework.
Main problems:
* For getUsage() to contain a full description of what my top-level
command can do, it takes multiple lines. But Felix then shows the
whole thing from the help command.
* Putting all the commands as methods on one class starts to become
unmanageable and then you create a sub-command API, and:
* The API for sub-commands looks awfully similar to the API for commands.
Possible resolution:
In my case I went with the main command parsing its first argument and
then switching to different methods.
I started wondering if there was a "proper" way to do this, and on
investigation I see other commands doing this all themselves too, like
"obr help". Why not invert it? Can't "help" show obr in the list
with a getShortUsage(), and then "help obr" shows the list of
sub-commands? You could almost allow getName() to contain spaces and
then improve the shell to do better matching. Or you could have an
explicit API for getting the sub-commands for a given command, and
then each one can have shortUsage and fullUsage.
I don't want to turn this into a "let's design a Command API"
discussion, but _if_ I were writing a new command API from scratch, I
guess ideally I would like to see this bare minimum:
public interface Command {
// If a top-level service comment then this needs to be unique
in the shell service.
String getName();
// "help" or "help obr" would show these:
String getShortUsage();
String getShortDescription();
// "help obr list" would show these:
String getFullUsage();
String getFullDescription();
/**
* Executes a command.
*
* @param context the context in which the command is being
run. All parameters passed through here.
*/
public void execute(CommandContext context);
/**
* Gets all sub-commands. These are commands where {@link #getName()}
* would return the name of the sub-command,
*/
Command[] getSubCommands();
}
public interface CommandContext {
String getCommandLine();
String[] getCommand();
PrintStream getErrorStream();
PrintStream getOutputStream();
}
Good points:
* You can extend the context later without disrupting the API
Deficiencies:
* On the other hand extending the *context* isn't possible. Commons
Chain solves this for their command model by going all out and just
putting a map in there, which is possibly too much. (And well,
they're not a shell either. So you would have to pass out and err
streams as parameters too, to actually use that.)
* Still passes the full command in the parameters. Purists would say
this is pointless and that it would be more reusable if it only passed
the parameters, which would make it possible to change the location of
commands in the tree without rewriting the command.
But... why develop a brand new command API? There are already two
good ones out there which I'm aware of...
1. GShell's Command API - GShell is also in itself a good shell too,
with proper autocompletion for commands, and this is exposed
throughout the API as well.
2. JNode's Command API - I have seen people tout JNode's as being
better than GShell... but it is LGPL but JNode have never really
advertised their code base as a collection of reusable components.
Both of these are trying to solve the same problem of making a generic
API where commands, help, completion and everything are considered. I
would say JNode's is marginally better because if its notion of
argument types.
I guess what I'm wondering is, was there a particular reason Felix's
is the way it is, or is it because the codebase was pull in from
wherever and nobody has really used it intensively yet?
TX
P.S. And on a side-note... I have been wondering how to get
user-level access control for commands, to control who can do what.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stevens Gestin wrote:
> This could be done through an "extended" BNF instead of parameter list.
>
Yes, it could be possible for commands to supply their own BNF. Other
possibilities include using the reflection capabilities of Java to see
which parameter types and number the command expects, perhaps.
-> richard
> On Thu, Jan 8, 2009 at 1:10 PM, Trejkaz <tr...@trypticon.org> wrote:
>
>
>>> For me parameter completion is still part of the shell UI, not
>>> part of the core shell API. The core shell API has to be defined
>>> in such a way to make some of these features possible; for
>>> example, if the shell API has no way to list available commands,
>>> then there is no way to do command completion.
>>>
>> Likewise, if the shell has no way to list the types of the parameters
>> for the commands, then there is no way to do parameter completion in
>> the shell UI. Otherwise how will it know if what you're typing is a
>> username or a filename?
>>
>> TX
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by Stevens Gestin <sg...@gmail.com>.
This could be done through an "extended" BNF instead of parameter list.
On Thu, Jan 8, 2009 at 1:10 PM, Trejkaz <tr...@trypticon.org> wrote:
> > For me parameter completion is still part of the shell UI, not
> > part of the core shell API. The core shell API has to be defined
> > in such a way to make some of these features possible; for
> > example, if the shell API has no way to list available commands,
> > then there is no way to do command completion.
>
> Likewise, if the shell has no way to list the types of the parameters
> for the commands, then there is no way to do parameter completion in
> the shell UI. Otherwise how will it know if what you're typing is a
> username or a filename?
>
> TX
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Le respect commence par celui de l'environnement
Re: The Command API (Felix Shell)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Trejkaz wrote:
>> For me parameter completion is still part of the shell UI, not
>> part of the core shell API. The core shell API has to be defined
>> in such a way to make some of these features possible; for
>> example, if the shell API has no way to list available commands,
>> then there is no way to do command completion.
>>
>
> Likewise, if the shell has no way to list the types of the parameters
> for the commands, then there is no way to do parameter completion in
> the shell UI. Otherwise how will it know if what you're typing is a
> username or a filename?
>
Agreed. That was my point. The API has to make it possible, but it
doesn't actually do it, the UI does.
-> richard
> TX
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by Trejkaz <tr...@trypticon.org>.
> For me parameter completion is still part of the shell UI, not
> part of the core shell API. The core shell API has to be defined
> in such a way to make some of these features possible; for
> example, if the shell API has no way to list available commands,
> then there is no way to do command completion.
Likewise, if the shell has no way to list the types of the parameters
for the commands, then there is no way to do parameter completion in
the shell UI. Otherwise how will it know if what you're typing is a
username or a filename?
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Trejkaz wrote:
> On Thu, Jan 1, 2009 at 3:25 AM, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> p.s. There is a difference between command API and things like command
>> completion and history. The former deals with core capabilities, while the
>> latter deals with UI issues. The core shouldn't assume a UI. Sometimes it
>> seems that people lump these two together.
>>
>
> Command completion, yes. Parameter completion (which is what normal
> shell users expect these days), no. Take the following:
>
> ls --<tab>
>
> How can the shell determine the list of possible completions?
>
> #1: Have a method where you pass the current String[] and the partial
> input for the next parameter, and it returns an array of possible
> completions for the parameter.
>
> #2: Add semantics for commands so that a command can be interrogated
> for its list of flags and the type of its arguments.
>
> It's not like this is useful only from a real console. If #2 were
> implemented then a web page would be able to generate a pretty form
> for executing a command, instead of the user having to type out the
> string. :-)
>
> Granted some shell interfaces won't have a way to complete (command
> via instant message for instance.) So maybe this sort of rich shell
> command needs to be a sub-interface.
>
For me parameter completion is still part of the shell UI, not part of
the core shell API. The core shell API has to be defined in such a way
to make some of these features possible; for example, if the shell API
has no way to list available commands, then there is no way to do
command completion.
Perhaps we are suffering from a terminology issue here, since normally
when we say "shell" we think of something that both reads input from the
user and executes the commands. For our scenario, we have broken this in
half: one half executes commands and the other half reads input from the
user (and somehow delegates to the other half). I am calling that first
part the shell and the second part the shell UI.
-> richard
> TX
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by Trejkaz <tr...@trypticon.org>.
On Thu, Jan 1, 2009 at 3:25 AM, Richard S. Hall <he...@ungoverned.org> wrote:
> p.s. There is a difference between command API and things like command
> completion and history. The former deals with core capabilities, while the
> latter deals with UI issues. The core shouldn't assume a UI. Sometimes it
> seems that people lump these two together.
Command completion, yes. Parameter completion (which is what normal
shell users expect these days), no. Take the following:
ls --<tab>
How can the shell determine the list of possible completions?
#1: Have a method where you pass the current String[] and the partial
input for the next parameter, and it returns an array of possible
completions for the parameter.
#2: Add semantics for commands so that a command can be interrogated
for its list of flags and the type of its arguments.
It's not like this is useful only from a real console. If #2 were
implemented then a web page would be able to generate a pretty form
for executing a command, instead of the user having to type out the
string. :-)
Granted some shell interfaces won't have a way to complete (command
via instant message for instance.) So maybe this sort of rich shell
command needs to be a sub-interface.
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stevens Gestin wrote:
> That's the right way to do. Shell UI is responsible for user interaction and
> completion of commands and parameters.
>
> Where can I download early draft of R4.2 .
>
From the OSGi web site...look under the news section.
-> richard
> Stevens
>
> On Wed, Jan 7, 2009 at 4:08 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>
>> Sounds nice. You should check out RFC 132 in the R4.2 early draft to get
>> some ideas about the direction of the potential shell.
>>
>> -> richard
>>
>>
>>
>> Stevens Gestin wrote:
>>
>>
>>> Hi,
>>>
>>> it seems quiet a good news that replacement of current shell API is on
>>> rail.
>>>
>>> Of course you are right to mentions that shell API must not deal with UI
>>> functionalities. It's completly two different things. You have the shell
>>> engine which execute commands and the UI engine which is responsible for
>>> completion and interaction with users.
>>>
>>> In our implementation, commands can read through a stdin. Chaining
>>> commands
>>> links stdout of command N to stdin of command N+1. Interaction with user
>>> through the first stdin is done with a UI Shell service.
>>>
>>> I also implements a very simple formula engine which allow us to set a
>>> variable like this:
>>> webserver.port = {clientserver.port} + 1
>>> or
>>> webserver.root = {install.directory} + "\components\webserver\war"
>>>
>>> This allow us to simplify configuration of our application.
>>>
>>> In our server, we use the shell service as the core component. We interact
>>> with the OSGI services through the shell service. This simplify
>>> considerably
>>> configuration of Felix startup.
>>>
>>> We can record scripts and re-excute them later.
>>>
>>> Best Regards,
>>> Stevens
>>>
>>>
>>> On Wed, Dec 31, 2008 at 5:25 PM, Richard S. Hall <heavy@ungoverned.org
>>>
>>>> wrote:
>>>>
>>>
>>>
>>>> The shell API is very, very simple (and simplistic). It was never
>>>> intended
>>>> to be a thing of beauty. It has been around for 6 or 7 years purely as a
>>>> simple means of interacting with the running framework. It was never
>>>> intended to be a killer app for Felix.
>>>>
>>>> However, I am not against improving it or even completely replacing it.
>>>> The
>>>> main thing I have thought about improving is allowing commands to have a
>>>> stdin so they can be more interactive. But we have to remember that it
>>>> would
>>>> be nice for the shell to remain reasonably lightweight and compatible
>>>> with
>>>> different Java platforms.
>>>>
>>>> There is actually some work within the OSGi Alliance to move toward a
>>>> standard shell and we may be involved in that...I don't have more details
>>>> on
>>>> it yet, but it is part of RFC 132 from the early spec draft.
>>>>
>>>> So, this area is looking like it could change before long.
>>>>
>>>> -> richard
>>>>
>>>> p.s. There is a difference between command API and things like command
>>>> completion and history. The former deals with core capabilities, while
>>>> the
>>>> latter deals with UI issues. The core shouldn't assume a UI. Sometimes it
>>>> seems that people lump these two together.
>>>>
>>>> Stevens Gestin wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>> I've already sent an email concerning limitation of Command interface
>>>>> few
>>>>> months ago. I totally developted a shell engine from scratch.
>>>>>
>>>>> My shell is registering in OSGI container as a service. Other services
>>>>> register ShellExtension. Registration of extension initiate an update
>>>>> process on the shell service. Shell extension provides a simple
>>>>> interface
>>>>> which allow retrieval of extension commands. Each command provides
>>>>> information like short help, complete help, description and version.
>>>>>
>>>>> You can chain commands, use variables (in global shell context or
>>>>> session
>>>>> context). It supports short and long option (- and -- flags),
>>>>> whitespaces
>>>>> and some other features.
>>>>>
>>>>> Best Regards,
>>>>> Stevens
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 31, 2008 at 1:02 PM, Trejkaz <tr...@trypticon.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The Command API is currently...
>>>>>>
>>>>>> public void execute(String command, PrintStream out, PrintStream err)
>>>>>>
>>>>>> After having written a few commands, I find myself doing two things a
>>>>>> lot.
>>>>>>
>>>>>> Firstly, I find myself parsing command-lines.
>>>>>>
>>>>>> Currently all my parameters are whitespace-free but that's about to
>>>>>> change. So now I need a full parser which handles quotes in a
>>>>>> sensible fashion consistent with my other commands, and indeed Felix's
>>>>>> existing commands.
>>>>>>
>>>>>> It seems like the ultimate solution to this part would have been to
>>>>>> pass the command as a String[] instead of the raw command. Obviously
>>>>>> I can write my own convenience API for this, but I started wondering
>>>>>> if Felix is already hiding something like this..?
>>>>>>
>>>>>> Secondly, I find myself wondering how to handle sub-commands. And
>>>>>> this is where the mail gets big. Sorry about that. for tl;dr types,
>>>>>> scroll down to my proposed interfaces and points below those.
>>>>>>
>>>>>> Effectively having solved the parser problem already (which I haven't
>>>>>> solved correctly actually, but for the sake of discussion - the real
>>>>>> code splits on \s+) I now find myself implementing my own sub-command
>>>>>> framework.
>>>>>>
>>>>>> Main problems:
>>>>>>
>>>>>> * For getUsage() to contain a full description of what my top-level
>>>>>> command can do, it takes multiple lines. But Felix then shows the
>>>>>> whole thing from the help command.
>>>>>> * Putting all the commands as methods on one class starts to become
>>>>>> unmanageable and then you create a sub-command API, and:
>>>>>> * The API for sub-commands looks awfully similar to the API for
>>>>>> commands.
>>>>>>
>>>>>> Possible resolution:
>>>>>>
>>>>>> In my case I went with the main command parsing its first argument and
>>>>>> then switching to different methods.
>>>>>>
>>>>>> I started wondering if there was a "proper" way to do this, and on
>>>>>> investigation I see other commands doing this all themselves too, like
>>>>>> "obr help". Why not invert it? Can't "help" show obr in the list
>>>>>> with a getShortUsage(), and then "help obr" shows the list of
>>>>>> sub-commands? You could almost allow getName() to contain spaces and
>>>>>> then improve the shell to do better matching. Or you could have an
>>>>>> explicit API for getting the sub-commands for a given command, and
>>>>>> then each one can have shortUsage and fullUsage.
>>>>>>
>>>>>> I don't want to turn this into a "let's design a Command API"
>>>>>> discussion, but _if_ I were writing a new command API from scratch, I
>>>>>> guess ideally I would like to see this bare minimum:
>>>>>>
>>>>>> public interface Command {
>>>>>>
>>>>>> // If a top-level service comment then this needs to be unique
>>>>>> in the shell service.
>>>>>> String getName();
>>>>>>
>>>>>> // "help" or "help obr" would show these:
>>>>>> String getShortUsage();
>>>>>> String getShortDescription();
>>>>>>
>>>>>> // "help obr list" would show these:
>>>>>> String getFullUsage();
>>>>>> String getFullDescription();
>>>>>>
>>>>>> /**
>>>>>> * Executes a command.
>>>>>> *
>>>>>> * @param context the context in which the command is being
>>>>>> run. All parameters passed through here.
>>>>>> */
>>>>>> public void execute(CommandContext context);
>>>>>>
>>>>>> /**
>>>>>> * Gets all sub-commands. These are commands where {@link
>>>>>> #getName()}
>>>>>> * would return the name of the sub-command,
>>>>>> */
>>>>>> Command[] getSubCommands();
>>>>>> }
>>>>>>
>>>>>> public interface CommandContext {
>>>>>> String getCommandLine();
>>>>>> String[] getCommand();
>>>>>> PrintStream getErrorStream();
>>>>>> PrintStream getOutputStream();
>>>>>> }
>>>>>>
>>>>>> Good points:
>>>>>> * You can extend the context later without disrupting the API
>>>>>>
>>>>>> Deficiencies:
>>>>>> * On the other hand extending the *context* isn't possible. Commons
>>>>>> Chain solves this for their command model by going all out and just
>>>>>> putting a map in there, which is possibly too much. (And well,
>>>>>> they're not a shell either. So you would have to pass out and err
>>>>>> streams as parameters too, to actually use that.)
>>>>>> * Still passes the full command in the parameters. Purists would say
>>>>>> this is pointless and that it would be more reusable if it only passed
>>>>>> the parameters, which would make it possible to change the location of
>>>>>> commands in the tree without rewriting the command.
>>>>>>
>>>>>> But... why develop a brand new command API? There are already two
>>>>>> good ones out there which I'm aware of...
>>>>>>
>>>>>> 1. GShell's Command API - GShell is also in itself a good shell too,
>>>>>> with proper autocompletion for commands, and this is exposed
>>>>>> throughout the API as well.
>>>>>>
>>>>>> 2. JNode's Command API - I have seen people tout JNode's as being
>>>>>> better than GShell... but it is LGPL but JNode have never really
>>>>>> advertised their code base as a collection of reusable components.
>>>>>>
>>>>>> Both of these are trying to solve the same problem of making a generic
>>>>>> API where commands, help, completion and everything are considered. I
>>>>>> would say JNode's is marginally better because if its notion of
>>>>>> argument types.
>>>>>>
>>>>>> I guess what I'm wondering is, was there a particular reason Felix's
>>>>>> is the way it is, or is it because the codebase was pull in from
>>>>>> wherever and nobody has really used it intensively yet?
>>>>>>
>>>>>>
>>>>>> TX
>>>>>>
>>>>>> P.S. And on a side-note... I have been wondering how to get
>>>>>> user-level access control for commands, to control who can do what.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by Stevens Gestin <sg...@gmail.com>.
That's the right way to do. Shell UI is responsible for user interaction and
completion of commands and parameters.
Where can I download early draft of R4.2 .
Stevens
On Wed, Jan 7, 2009 at 4:08 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Sounds nice. You should check out RFC 132 in the R4.2 early draft to get
> some ideas about the direction of the potential shell.
>
> -> richard
>
>
>
> Stevens Gestin wrote:
>
>> Hi,
>>
>> it seems quiet a good news that replacement of current shell API is on
>> rail.
>>
>> Of course you are right to mentions that shell API must not deal with UI
>> functionalities. It's completly two different things. You have the shell
>> engine which execute commands and the UI engine which is responsible for
>> completion and interaction with users.
>>
>> In our implementation, commands can read through a stdin. Chaining
>> commands
>> links stdout of command N to stdin of command N+1. Interaction with user
>> through the first stdin is done with a UI Shell service.
>>
>> I also implements a very simple formula engine which allow us to set a
>> variable like this:
>> webserver.port = {clientserver.port} + 1
>> or
>> webserver.root = {install.directory} + "\components\webserver\war"
>>
>> This allow us to simplify configuration of our application.
>>
>> In our server, we use the shell service as the core component. We interact
>> with the OSGI services through the shell service. This simplify
>> considerably
>> configuration of Felix startup.
>>
>> We can record scripts and re-excute them later.
>>
>> Best Regards,
>> Stevens
>>
>>
>> On Wed, Dec 31, 2008 at 5:25 PM, Richard S. Hall <heavy@ungoverned.org
>> >wrote:
>>
>>
>>
>>> The shell API is very, very simple (and simplistic). It was never
>>> intended
>>> to be a thing of beauty. It has been around for 6 or 7 years purely as a
>>> simple means of interacting with the running framework. It was never
>>> intended to be a killer app for Felix.
>>>
>>> However, I am not against improving it or even completely replacing it.
>>> The
>>> main thing I have thought about improving is allowing commands to have a
>>> stdin so they can be more interactive. But we have to remember that it
>>> would
>>> be nice for the shell to remain reasonably lightweight and compatible
>>> with
>>> different Java platforms.
>>>
>>> There is actually some work within the OSGi Alliance to move toward a
>>> standard shell and we may be involved in that...I don't have more details
>>> on
>>> it yet, but it is part of RFC 132 from the early spec draft.
>>>
>>> So, this area is looking like it could change before long.
>>>
>>> -> richard
>>>
>>> p.s. There is a difference between command API and things like command
>>> completion and history. The former deals with core capabilities, while
>>> the
>>> latter deals with UI issues. The core shouldn't assume a UI. Sometimes it
>>> seems that people lump these two together.
>>>
>>> Stevens Gestin wrote:
>>>
>>>
>>>
>>>> Hi,
>>>> I've already sent an email concerning limitation of Command interface
>>>> few
>>>> months ago. I totally developted a shell engine from scratch.
>>>>
>>>> My shell is registering in OSGI container as a service. Other services
>>>> register ShellExtension. Registration of extension initiate an update
>>>> process on the shell service. Shell extension provides a simple
>>>> interface
>>>> which allow retrieval of extension commands. Each command provides
>>>> information like short help, complete help, description and version.
>>>>
>>>> You can chain commands, use variables (in global shell context or
>>>> session
>>>> context). It supports short and long option (- and -- flags),
>>>> whitespaces
>>>> and some other features.
>>>>
>>>> Best Regards,
>>>> Stevens
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Dec 31, 2008 at 1:02 PM, Trejkaz <tr...@trypticon.org> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> The Command API is currently...
>>>>>
>>>>> public void execute(String command, PrintStream out, PrintStream err)
>>>>>
>>>>> After having written a few commands, I find myself doing two things a
>>>>> lot.
>>>>>
>>>>> Firstly, I find myself parsing command-lines.
>>>>>
>>>>> Currently all my parameters are whitespace-free but that's about to
>>>>> change. So now I need a full parser which handles quotes in a
>>>>> sensible fashion consistent with my other commands, and indeed Felix's
>>>>> existing commands.
>>>>>
>>>>> It seems like the ultimate solution to this part would have been to
>>>>> pass the command as a String[] instead of the raw command. Obviously
>>>>> I can write my own convenience API for this, but I started wondering
>>>>> if Felix is already hiding something like this..?
>>>>>
>>>>> Secondly, I find myself wondering how to handle sub-commands. And
>>>>> this is where the mail gets big. Sorry about that. for tl;dr types,
>>>>> scroll down to my proposed interfaces and points below those.
>>>>>
>>>>> Effectively having solved the parser problem already (which I haven't
>>>>> solved correctly actually, but for the sake of discussion - the real
>>>>> code splits on \s+) I now find myself implementing my own sub-command
>>>>> framework.
>>>>>
>>>>> Main problems:
>>>>>
>>>>> * For getUsage() to contain a full description of what my top-level
>>>>> command can do, it takes multiple lines. But Felix then shows the
>>>>> whole thing from the help command.
>>>>> * Putting all the commands as methods on one class starts to become
>>>>> unmanageable and then you create a sub-command API, and:
>>>>> * The API for sub-commands looks awfully similar to the API for
>>>>> commands.
>>>>>
>>>>> Possible resolution:
>>>>>
>>>>> In my case I went with the main command parsing its first argument and
>>>>> then switching to different methods.
>>>>>
>>>>> I started wondering if there was a "proper" way to do this, and on
>>>>> investigation I see other commands doing this all themselves too, like
>>>>> "obr help". Why not invert it? Can't "help" show obr in the list
>>>>> with a getShortUsage(), and then "help obr" shows the list of
>>>>> sub-commands? You could almost allow getName() to contain spaces and
>>>>> then improve the shell to do better matching. Or you could have an
>>>>> explicit API for getting the sub-commands for a given command, and
>>>>> then each one can have shortUsage and fullUsage.
>>>>>
>>>>> I don't want to turn this into a "let's design a Command API"
>>>>> discussion, but _if_ I were writing a new command API from scratch, I
>>>>> guess ideally I would like to see this bare minimum:
>>>>>
>>>>> public interface Command {
>>>>>
>>>>> // If a top-level service comment then this needs to be unique
>>>>> in the shell service.
>>>>> String getName();
>>>>>
>>>>> // "help" or "help obr" would show these:
>>>>> String getShortUsage();
>>>>> String getShortDescription();
>>>>>
>>>>> // "help obr list" would show these:
>>>>> String getFullUsage();
>>>>> String getFullDescription();
>>>>>
>>>>> /**
>>>>> * Executes a command.
>>>>> *
>>>>> * @param context the context in which the command is being
>>>>> run. All parameters passed through here.
>>>>> */
>>>>> public void execute(CommandContext context);
>>>>>
>>>>> /**
>>>>> * Gets all sub-commands. These are commands where {@link
>>>>> #getName()}
>>>>> * would return the name of the sub-command,
>>>>> */
>>>>> Command[] getSubCommands();
>>>>> }
>>>>>
>>>>> public interface CommandContext {
>>>>> String getCommandLine();
>>>>> String[] getCommand();
>>>>> PrintStream getErrorStream();
>>>>> PrintStream getOutputStream();
>>>>> }
>>>>>
>>>>> Good points:
>>>>> * You can extend the context later without disrupting the API
>>>>>
>>>>> Deficiencies:
>>>>> * On the other hand extending the *context* isn't possible. Commons
>>>>> Chain solves this for their command model by going all out and just
>>>>> putting a map in there, which is possibly too much. (And well,
>>>>> they're not a shell either. So you would have to pass out and err
>>>>> streams as parameters too, to actually use that.)
>>>>> * Still passes the full command in the parameters. Purists would say
>>>>> this is pointless and that it would be more reusable if it only passed
>>>>> the parameters, which would make it possible to change the location of
>>>>> commands in the tree without rewriting the command.
>>>>>
>>>>> But... why develop a brand new command API? There are already two
>>>>> good ones out there which I'm aware of...
>>>>>
>>>>> 1. GShell's Command API - GShell is also in itself a good shell too,
>>>>> with proper autocompletion for commands, and this is exposed
>>>>> throughout the API as well.
>>>>>
>>>>> 2. JNode's Command API - I have seen people tout JNode's as being
>>>>> better than GShell... but it is LGPL but JNode have never really
>>>>> advertised their code base as a collection of reusable components.
>>>>>
>>>>> Both of these are trying to solve the same problem of making a generic
>>>>> API where commands, help, completion and everything are considered. I
>>>>> would say JNode's is marginally better because if its notion of
>>>>> argument types.
>>>>>
>>>>> I guess what I'm wondering is, was there a particular reason Felix's
>>>>> is the way it is, or is it because the codebase was pull in from
>>>>> wherever and nobody has really used it intensively yet?
>>>>>
>>>>>
>>>>> TX
>>>>>
>>>>> P.S. And on a side-note... I have been wondering how to get
>>>>> user-level access control for commands, to control who can do what.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Le respect commence par celui de l'environnement
Re: The Command API (Felix Shell)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Sounds nice. You should check out RFC 132 in the R4.2 early draft to get
some ideas about the direction of the potential shell.
-> richard
Stevens Gestin wrote:
> Hi,
>
> it seems quiet a good news that replacement of current shell API is on rail.
>
> Of course you are right to mentions that shell API must not deal with UI
> functionalities. It's completly two different things. You have the shell
> engine which execute commands and the UI engine which is responsible for
> completion and interaction with users.
>
> In our implementation, commands can read through a stdin. Chaining commands
> links stdout of command N to stdin of command N+1. Interaction with user
> through the first stdin is done with a UI Shell service.
>
> I also implements a very simple formula engine which allow us to set a
> variable like this:
> webserver.port = {clientserver.port} + 1
> or
> webserver.root = {install.directory} + "\components\webserver\war"
>
> This allow us to simplify configuration of our application.
>
> In our server, we use the shell service as the core component. We interact
> with the OSGI services through the shell service. This simplify considerably
> configuration of Felix startup.
>
> We can record scripts and re-excute them later.
>
> Best Regards,
> Stevens
>
>
> On Wed, Dec 31, 2008 at 5:25 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>
>> The shell API is very, very simple (and simplistic). It was never intended
>> to be a thing of beauty. It has been around for 6 or 7 years purely as a
>> simple means of interacting with the running framework. It was never
>> intended to be a killer app for Felix.
>>
>> However, I am not against improving it or even completely replacing it. The
>> main thing I have thought about improving is allowing commands to have a
>> stdin so they can be more interactive. But we have to remember that it would
>> be nice for the shell to remain reasonably lightweight and compatible with
>> different Java platforms.
>>
>> There is actually some work within the OSGi Alliance to move toward a
>> standard shell and we may be involved in that...I don't have more details on
>> it yet, but it is part of RFC 132 from the early spec draft.
>>
>> So, this area is looking like it could change before long.
>>
>> -> richard
>>
>> p.s. There is a difference between command API and things like command
>> completion and history. The former deals with core capabilities, while the
>> latter deals with UI issues. The core shouldn't assume a UI. Sometimes it
>> seems that people lump these two together.
>>
>> Stevens Gestin wrote:
>>
>>
>>> Hi,
>>> I've already sent an email concerning limitation of Command interface few
>>> months ago. I totally developted a shell engine from scratch.
>>>
>>> My shell is registering in OSGI container as a service. Other services
>>> register ShellExtension. Registration of extension initiate an update
>>> process on the shell service. Shell extension provides a simple interface
>>> which allow retrieval of extension commands. Each command provides
>>> information like short help, complete help, description and version.
>>>
>>> You can chain commands, use variables (in global shell context or session
>>> context). It supports short and long option (- and -- flags), whitespaces
>>> and some other features.
>>>
>>> Best Regards,
>>> Stevens
>>>
>>>
>>>
>>>
>>> On Wed, Dec 31, 2008 at 1:02 PM, Trejkaz <tr...@trypticon.org> wrote:
>>>
>>>
>>>
>>>
>>>> The Command API is currently...
>>>>
>>>> public void execute(String command, PrintStream out, PrintStream err)
>>>>
>>>> After having written a few commands, I find myself doing two things a
>>>> lot.
>>>>
>>>> Firstly, I find myself parsing command-lines.
>>>>
>>>> Currently all my parameters are whitespace-free but that's about to
>>>> change. So now I need a full parser which handles quotes in a
>>>> sensible fashion consistent with my other commands, and indeed Felix's
>>>> existing commands.
>>>>
>>>> It seems like the ultimate solution to this part would have been to
>>>> pass the command as a String[] instead of the raw command. Obviously
>>>> I can write my own convenience API for this, but I started wondering
>>>> if Felix is already hiding something like this..?
>>>>
>>>> Secondly, I find myself wondering how to handle sub-commands. And
>>>> this is where the mail gets big. Sorry about that. for tl;dr types,
>>>> scroll down to my proposed interfaces and points below those.
>>>>
>>>> Effectively having solved the parser problem already (which I haven't
>>>> solved correctly actually, but for the sake of discussion - the real
>>>> code splits on \s+) I now find myself implementing my own sub-command
>>>> framework.
>>>>
>>>> Main problems:
>>>>
>>>> * For getUsage() to contain a full description of what my top-level
>>>> command can do, it takes multiple lines. But Felix then shows the
>>>> whole thing from the help command.
>>>> * Putting all the commands as methods on one class starts to become
>>>> unmanageable and then you create a sub-command API, and:
>>>> * The API for sub-commands looks awfully similar to the API for commands.
>>>>
>>>> Possible resolution:
>>>>
>>>> In my case I went with the main command parsing its first argument and
>>>> then switching to different methods.
>>>>
>>>> I started wondering if there was a "proper" way to do this, and on
>>>> investigation I see other commands doing this all themselves too, like
>>>> "obr help". Why not invert it? Can't "help" show obr in the list
>>>> with a getShortUsage(), and then "help obr" shows the list of
>>>> sub-commands? You could almost allow getName() to contain spaces and
>>>> then improve the shell to do better matching. Or you could have an
>>>> explicit API for getting the sub-commands for a given command, and
>>>> then each one can have shortUsage and fullUsage.
>>>>
>>>> I don't want to turn this into a "let's design a Command API"
>>>> discussion, but _if_ I were writing a new command API from scratch, I
>>>> guess ideally I would like to see this bare minimum:
>>>>
>>>> public interface Command {
>>>>
>>>> // If a top-level service comment then this needs to be unique
>>>> in the shell service.
>>>> String getName();
>>>>
>>>> // "help" or "help obr" would show these:
>>>> String getShortUsage();
>>>> String getShortDescription();
>>>>
>>>> // "help obr list" would show these:
>>>> String getFullUsage();
>>>> String getFullDescription();
>>>>
>>>> /**
>>>> * Executes a command.
>>>> *
>>>> * @param context the context in which the command is being
>>>> run. All parameters passed through here.
>>>> */
>>>> public void execute(CommandContext context);
>>>>
>>>> /**
>>>> * Gets all sub-commands. These are commands where {@link
>>>> #getName()}
>>>> * would return the name of the sub-command,
>>>> */
>>>> Command[] getSubCommands();
>>>> }
>>>>
>>>> public interface CommandContext {
>>>> String getCommandLine();
>>>> String[] getCommand();
>>>> PrintStream getErrorStream();
>>>> PrintStream getOutputStream();
>>>> }
>>>>
>>>> Good points:
>>>> * You can extend the context later without disrupting the API
>>>>
>>>> Deficiencies:
>>>> * On the other hand extending the *context* isn't possible. Commons
>>>> Chain solves this for their command model by going all out and just
>>>> putting a map in there, which is possibly too much. (And well,
>>>> they're not a shell either. So you would have to pass out and err
>>>> streams as parameters too, to actually use that.)
>>>> * Still passes the full command in the parameters. Purists would say
>>>> this is pointless and that it would be more reusable if it only passed
>>>> the parameters, which would make it possible to change the location of
>>>> commands in the tree without rewriting the command.
>>>>
>>>> But... why develop a brand new command API? There are already two
>>>> good ones out there which I'm aware of...
>>>>
>>>> 1. GShell's Command API - GShell is also in itself a good shell too,
>>>> with proper autocompletion for commands, and this is exposed
>>>> throughout the API as well.
>>>>
>>>> 2. JNode's Command API - I have seen people tout JNode's as being
>>>> better than GShell... but it is LGPL but JNode have never really
>>>> advertised their code base as a collection of reusable components.
>>>>
>>>> Both of these are trying to solve the same problem of making a generic
>>>> API where commands, help, completion and everything are considered. I
>>>> would say JNode's is marginally better because if its notion of
>>>> argument types.
>>>>
>>>> I guess what I'm wondering is, was there a particular reason Felix's
>>>> is the way it is, or is it because the codebase was pull in from
>>>> wherever and nobody has really used it intensively yet?
>>>>
>>>>
>>>> TX
>>>>
>>>> P.S. And on a side-note... I have been wondering how to get
>>>> user-level access control for commands, to control who can do what.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by Stevens Gestin <sg...@gmail.com>.
Hi,
it seems quiet a good news that replacement of current shell API is on rail.
Of course you are right to mentions that shell API must not deal with UI
functionalities. It's completly two different things. You have the shell
engine which execute commands and the UI engine which is responsible for
completion and interaction with users.
In our implementation, commands can read through a stdin. Chaining commands
links stdout of command N to stdin of command N+1. Interaction with user
through the first stdin is done with a UI Shell service.
I also implements a very simple formula engine which allow us to set a
variable like this:
webserver.port = {clientserver.port} + 1
or
webserver.root = {install.directory} + "\components\webserver\war"
This allow us to simplify configuration of our application.
In our server, we use the shell service as the core component. We interact
with the OSGI services through the shell service. This simplify considerably
configuration of Felix startup.
We can record scripts and re-excute them later.
Best Regards,
Stevens
On Wed, Dec 31, 2008 at 5:25 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> The shell API is very, very simple (and simplistic). It was never intended
> to be a thing of beauty. It has been around for 6 or 7 years purely as a
> simple means of interacting with the running framework. It was never
> intended to be a killer app for Felix.
>
> However, I am not against improving it or even completely replacing it. The
> main thing I have thought about improving is allowing commands to have a
> stdin so they can be more interactive. But we have to remember that it would
> be nice for the shell to remain reasonably lightweight and compatible with
> different Java platforms.
>
> There is actually some work within the OSGi Alliance to move toward a
> standard shell and we may be involved in that...I don't have more details on
> it yet, but it is part of RFC 132 from the early spec draft.
>
> So, this area is looking like it could change before long.
>
> -> richard
>
> p.s. There is a difference between command API and things like command
> completion and history. The former deals with core capabilities, while the
> latter deals with UI issues. The core shouldn't assume a UI. Sometimes it
> seems that people lump these two together.
>
> Stevens Gestin wrote:
>
>> Hi,
>> I've already sent an email concerning limitation of Command interface few
>> months ago. I totally developted a shell engine from scratch.
>>
>> My shell is registering in OSGI container as a service. Other services
>> register ShellExtension. Registration of extension initiate an update
>> process on the shell service. Shell extension provides a simple interface
>> which allow retrieval of extension commands. Each command provides
>> information like short help, complete help, description and version.
>>
>> You can chain commands, use variables (in global shell context or session
>> context). It supports short and long option (- and -- flags), whitespaces
>> and some other features.
>>
>> Best Regards,
>> Stevens
>>
>>
>>
>>
>> On Wed, Dec 31, 2008 at 1:02 PM, Trejkaz <tr...@trypticon.org> wrote:
>>
>>
>>
>>> The Command API is currently...
>>>
>>> public void execute(String command, PrintStream out, PrintStream err)
>>>
>>> After having written a few commands, I find myself doing two things a
>>> lot.
>>>
>>> Firstly, I find myself parsing command-lines.
>>>
>>> Currently all my parameters are whitespace-free but that's about to
>>> change. So now I need a full parser which handles quotes in a
>>> sensible fashion consistent with my other commands, and indeed Felix's
>>> existing commands.
>>>
>>> It seems like the ultimate solution to this part would have been to
>>> pass the command as a String[] instead of the raw command. Obviously
>>> I can write my own convenience API for this, but I started wondering
>>> if Felix is already hiding something like this..?
>>>
>>> Secondly, I find myself wondering how to handle sub-commands. And
>>> this is where the mail gets big. Sorry about that. for tl;dr types,
>>> scroll down to my proposed interfaces and points below those.
>>>
>>> Effectively having solved the parser problem already (which I haven't
>>> solved correctly actually, but for the sake of discussion - the real
>>> code splits on \s+) I now find myself implementing my own sub-command
>>> framework.
>>>
>>> Main problems:
>>>
>>> * For getUsage() to contain a full description of what my top-level
>>> command can do, it takes multiple lines. But Felix then shows the
>>> whole thing from the help command.
>>> * Putting all the commands as methods on one class starts to become
>>> unmanageable and then you create a sub-command API, and:
>>> * The API for sub-commands looks awfully similar to the API for commands.
>>>
>>> Possible resolution:
>>>
>>> In my case I went with the main command parsing its first argument and
>>> then switching to different methods.
>>>
>>> I started wondering if there was a "proper" way to do this, and on
>>> investigation I see other commands doing this all themselves too, like
>>> "obr help". Why not invert it? Can't "help" show obr in the list
>>> with a getShortUsage(), and then "help obr" shows the list of
>>> sub-commands? You could almost allow getName() to contain spaces and
>>> then improve the shell to do better matching. Or you could have an
>>> explicit API for getting the sub-commands for a given command, and
>>> then each one can have shortUsage and fullUsage.
>>>
>>> I don't want to turn this into a "let's design a Command API"
>>> discussion, but _if_ I were writing a new command API from scratch, I
>>> guess ideally I would like to see this bare minimum:
>>>
>>> public interface Command {
>>>
>>> // If a top-level service comment then this needs to be unique
>>> in the shell service.
>>> String getName();
>>>
>>> // "help" or "help obr" would show these:
>>> String getShortUsage();
>>> String getShortDescription();
>>>
>>> // "help obr list" would show these:
>>> String getFullUsage();
>>> String getFullDescription();
>>>
>>> /**
>>> * Executes a command.
>>> *
>>> * @param context the context in which the command is being
>>> run. All parameters passed through here.
>>> */
>>> public void execute(CommandContext context);
>>>
>>> /**
>>> * Gets all sub-commands. These are commands where {@link
>>> #getName()}
>>> * would return the name of the sub-command,
>>> */
>>> Command[] getSubCommands();
>>> }
>>>
>>> public interface CommandContext {
>>> String getCommandLine();
>>> String[] getCommand();
>>> PrintStream getErrorStream();
>>> PrintStream getOutputStream();
>>> }
>>>
>>> Good points:
>>> * You can extend the context later without disrupting the API
>>>
>>> Deficiencies:
>>> * On the other hand extending the *context* isn't possible. Commons
>>> Chain solves this for their command model by going all out and just
>>> putting a map in there, which is possibly too much. (And well,
>>> they're not a shell either. So you would have to pass out and err
>>> streams as parameters too, to actually use that.)
>>> * Still passes the full command in the parameters. Purists would say
>>> this is pointless and that it would be more reusable if it only passed
>>> the parameters, which would make it possible to change the location of
>>> commands in the tree without rewriting the command.
>>>
>>> But... why develop a brand new command API? There are already two
>>> good ones out there which I'm aware of...
>>>
>>> 1. GShell's Command API - GShell is also in itself a good shell too,
>>> with proper autocompletion for commands, and this is exposed
>>> throughout the API as well.
>>>
>>> 2. JNode's Command API - I have seen people tout JNode's as being
>>> better than GShell... but it is LGPL but JNode have never really
>>> advertised their code base as a collection of reusable components.
>>>
>>> Both of these are trying to solve the same problem of making a generic
>>> API where commands, help, completion and everything are considered. I
>>> would say JNode's is marginally better because if its notion of
>>> argument types.
>>>
>>> I guess what I'm wondering is, was there a particular reason Felix's
>>> is the way it is, or is it because the codebase was pull in from
>>> wherever and nobody has really used it intensively yet?
>>>
>>>
>>> TX
>>>
>>> P.S. And on a side-note... I have been wondering how to get
>>> user-level access control for commands, to control who can do what.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Le respect commence par celui de l'environnement
Re: The Command API (Felix Shell)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
The shell API is very, very simple (and simplistic). It was never
intended to be a thing of beauty. It has been around for 6 or 7 years
purely as a simple means of interacting with the running framework. It
was never intended to be a killer app for Felix.
However, I am not against improving it or even completely replacing it.
The main thing I have thought about improving is allowing commands to
have a stdin so they can be more interactive. But we have to remember
that it would be nice for the shell to remain reasonably lightweight and
compatible with different Java platforms.
There is actually some work within the OSGi Alliance to move toward a
standard shell and we may be involved in that...I don't have more
details on it yet, but it is part of RFC 132 from the early spec draft.
So, this area is looking like it could change before long.
-> richard
p.s. There is a difference between command API and things like command
completion and history. The former deals with core capabilities, while
the latter deals with UI issues. The core shouldn't assume a UI.
Sometimes it seems that people lump these two together.
Stevens Gestin wrote:
> Hi,
> I've already sent an email concerning limitation of Command interface few
> months ago. I totally developted a shell engine from scratch.
>
> My shell is registering in OSGI container as a service. Other services
> register ShellExtension. Registration of extension initiate an update
> process on the shell service. Shell extension provides a simple interface
> which allow retrieval of extension commands. Each command provides
> information like short help, complete help, description and version.
>
> You can chain commands, use variables (in global shell context or session
> context). It supports short and long option (- and -- flags), whitespaces
> and some other features.
>
> Best Regards,
> Stevens
>
>
>
>
> On Wed, Dec 31, 2008 at 1:02 PM, Trejkaz <tr...@trypticon.org> wrote:
>
>
>> The Command API is currently...
>>
>> public void execute(String command, PrintStream out, PrintStream err)
>>
>> After having written a few commands, I find myself doing two things a lot.
>>
>> Firstly, I find myself parsing command-lines.
>>
>> Currently all my parameters are whitespace-free but that's about to
>> change. So now I need a full parser which handles quotes in a
>> sensible fashion consistent with my other commands, and indeed Felix's
>> existing commands.
>>
>> It seems like the ultimate solution to this part would have been to
>> pass the command as a String[] instead of the raw command. Obviously
>> I can write my own convenience API for this, but I started wondering
>> if Felix is already hiding something like this..?
>>
>> Secondly, I find myself wondering how to handle sub-commands. And
>> this is where the mail gets big. Sorry about that. for tl;dr types,
>> scroll down to my proposed interfaces and points below those.
>>
>> Effectively having solved the parser problem already (which I haven't
>> solved correctly actually, but for the sake of discussion - the real
>> code splits on \s+) I now find myself implementing my own sub-command
>> framework.
>>
>> Main problems:
>>
>> * For getUsage() to contain a full description of what my top-level
>> command can do, it takes multiple lines. But Felix then shows the
>> whole thing from the help command.
>> * Putting all the commands as methods on one class starts to become
>> unmanageable and then you create a sub-command API, and:
>> * The API for sub-commands looks awfully similar to the API for commands.
>>
>> Possible resolution:
>>
>> In my case I went with the main command parsing its first argument and
>> then switching to different methods.
>>
>> I started wondering if there was a "proper" way to do this, and on
>> investigation I see other commands doing this all themselves too, like
>> "obr help". Why not invert it? Can't "help" show obr in the list
>> with a getShortUsage(), and then "help obr" shows the list of
>> sub-commands? You could almost allow getName() to contain spaces and
>> then improve the shell to do better matching. Or you could have an
>> explicit API for getting the sub-commands for a given command, and
>> then each one can have shortUsage and fullUsage.
>>
>> I don't want to turn this into a "let's design a Command API"
>> discussion, but _if_ I were writing a new command API from scratch, I
>> guess ideally I would like to see this bare minimum:
>>
>> public interface Command {
>>
>> // If a top-level service comment then this needs to be unique
>> in the shell service.
>> String getName();
>>
>> // "help" or "help obr" would show these:
>> String getShortUsage();
>> String getShortDescription();
>>
>> // "help obr list" would show these:
>> String getFullUsage();
>> String getFullDescription();
>>
>> /**
>> * Executes a command.
>> *
>> * @param context the context in which the command is being
>> run. All parameters passed through here.
>> */
>> public void execute(CommandContext context);
>>
>> /**
>> * Gets all sub-commands. These are commands where {@link
>> #getName()}
>> * would return the name of the sub-command,
>> */
>> Command[] getSubCommands();
>> }
>>
>> public interface CommandContext {
>> String getCommandLine();
>> String[] getCommand();
>> PrintStream getErrorStream();
>> PrintStream getOutputStream();
>> }
>>
>> Good points:
>> * You can extend the context later without disrupting the API
>>
>> Deficiencies:
>> * On the other hand extending the *context* isn't possible. Commons
>> Chain solves this for their command model by going all out and just
>> putting a map in there, which is possibly too much. (And well,
>> they're not a shell either. So you would have to pass out and err
>> streams as parameters too, to actually use that.)
>> * Still passes the full command in the parameters. Purists would say
>> this is pointless and that it would be more reusable if it only passed
>> the parameters, which would make it possible to change the location of
>> commands in the tree without rewriting the command.
>>
>> But... why develop a brand new command API? There are already two
>> good ones out there which I'm aware of...
>>
>> 1. GShell's Command API - GShell is also in itself a good shell too,
>> with proper autocompletion for commands, and this is exposed
>> throughout the API as well.
>>
>> 2. JNode's Command API - I have seen people tout JNode's as being
>> better than GShell... but it is LGPL but JNode have never really
>> advertised their code base as a collection of reusable components.
>>
>> Both of these are trying to solve the same problem of making a generic
>> API where commands, help, completion and everything are considered. I
>> would say JNode's is marginally better because if its notion of
>> argument types.
>>
>> I guess what I'm wondering is, was there a particular reason Felix's
>> is the way it is, or is it because the codebase was pull in from
>> wherever and nobody has really used it intensively yet?
>>
>>
>> TX
>>
>> P.S. And on a side-note... I have been wondering how to get
>> user-level access control for commands, to control who can do what.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by Trejkaz <tr...@trypticon.org>.
On Thu, Jan 1, 2009 at 2:10 AM, Stevens Gestin <sg...@gmail.com> wrote:
> Hi,
> I've already sent an email concerning limitation of Command interface few
> months ago. I totally developted a shell engine from scratch.
>
> My shell is registering in OSGI container as a service. Other services
> register ShellExtension. Registration of extension initiate an update
> process on the shell service. Shell extension provides a simple interface
> which allow retrieval of extension commands. Each command provides
> information like short help, complete help, description and version.
>
> You can chain commands, use variables (in global shell context or session
> context). It supports short and long option (- and -- flags), whitespaces
> and some other features.
Do you build on top of the existing Felix Shell for all of this, or is
it a complete replacement? I was starting to think that maybe I would
just invent a new command interface which extends Felix's, and a
convenience base class to help implementing Felix's harder API
(basically, parse the command-line from the abstract class.) Then I
could still use Felix's shell, but potentially make my own shell
interface which treats instances of my command class as special (would
have to look up each kind of command service...)
More importantly though, is your shell code available? It sounds like
a pretty decent foundation.
In my case using an overridable context might turn out to be a
particularly good idea, as sometimes I want to know where the command
came from (some commands should work only if spoken in public, not on
the shell. But it seems I shouldn't be inventing a new command
interface just for chatroom commands, if it's still text commands
being executed at the end of the day.)
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: The Command API (Felix Shell)
Posted by Stevens Gestin <sg...@gmail.com>.
Hi,
I've already sent an email concerning limitation of Command interface few
months ago. I totally developted a shell engine from scratch.
My shell is registering in OSGI container as a service. Other services
register ShellExtension. Registration of extension initiate an update
process on the shell service. Shell extension provides a simple interface
which allow retrieval of extension commands. Each command provides
information like short help, complete help, description and version.
You can chain commands, use variables (in global shell context or session
context). It supports short and long option (- and -- flags), whitespaces
and some other features.
Best Regards,
Stevens
On Wed, Dec 31, 2008 at 1:02 PM, Trejkaz <tr...@trypticon.org> wrote:
> The Command API is currently...
>
> public void execute(String command, PrintStream out, PrintStream err)
>
> After having written a few commands, I find myself doing two things a lot.
>
> Firstly, I find myself parsing command-lines.
>
> Currently all my parameters are whitespace-free but that's about to
> change. So now I need a full parser which handles quotes in a
> sensible fashion consistent with my other commands, and indeed Felix's
> existing commands.
>
> It seems like the ultimate solution to this part would have been to
> pass the command as a String[] instead of the raw command. Obviously
> I can write my own convenience API for this, but I started wondering
> if Felix is already hiding something like this..?
>
> Secondly, I find myself wondering how to handle sub-commands. And
> this is where the mail gets big. Sorry about that. for tl;dr types,
> scroll down to my proposed interfaces and points below those.
>
> Effectively having solved the parser problem already (which I haven't
> solved correctly actually, but for the sake of discussion - the real
> code splits on \s+) I now find myself implementing my own sub-command
> framework.
>
> Main problems:
>
> * For getUsage() to contain a full description of what my top-level
> command can do, it takes multiple lines. But Felix then shows the
> whole thing from the help command.
> * Putting all the commands as methods on one class starts to become
> unmanageable and then you create a sub-command API, and:
> * The API for sub-commands looks awfully similar to the API for commands.
>
> Possible resolution:
>
> In my case I went with the main command parsing its first argument and
> then switching to different methods.
>
> I started wondering if there was a "proper" way to do this, and on
> investigation I see other commands doing this all themselves too, like
> "obr help". Why not invert it? Can't "help" show obr in the list
> with a getShortUsage(), and then "help obr" shows the list of
> sub-commands? You could almost allow getName() to contain spaces and
> then improve the shell to do better matching. Or you could have an
> explicit API for getting the sub-commands for a given command, and
> then each one can have shortUsage and fullUsage.
>
> I don't want to turn this into a "let's design a Command API"
> discussion, but _if_ I were writing a new command API from scratch, I
> guess ideally I would like to see this bare minimum:
>
> public interface Command {
>
> // If a top-level service comment then this needs to be unique
> in the shell service.
> String getName();
>
> // "help" or "help obr" would show these:
> String getShortUsage();
> String getShortDescription();
>
> // "help obr list" would show these:
> String getFullUsage();
> String getFullDescription();
>
> /**
> * Executes a command.
> *
> * @param context the context in which the command is being
> run. All parameters passed through here.
> */
> public void execute(CommandContext context);
>
> /**
> * Gets all sub-commands. These are commands where {@link
> #getName()}
> * would return the name of the sub-command,
> */
> Command[] getSubCommands();
> }
>
> public interface CommandContext {
> String getCommandLine();
> String[] getCommand();
> PrintStream getErrorStream();
> PrintStream getOutputStream();
> }
>
> Good points:
> * You can extend the context later without disrupting the API
>
> Deficiencies:
> * On the other hand extending the *context* isn't possible. Commons
> Chain solves this for their command model by going all out and just
> putting a map in there, which is possibly too much. (And well,
> they're not a shell either. So you would have to pass out and err
> streams as parameters too, to actually use that.)
> * Still passes the full command in the parameters. Purists would say
> this is pointless and that it would be more reusable if it only passed
> the parameters, which would make it possible to change the location of
> commands in the tree without rewriting the command.
>
> But... why develop a brand new command API? There are already two
> good ones out there which I'm aware of...
>
> 1. GShell's Command API - GShell is also in itself a good shell too,
> with proper autocompletion for commands, and this is exposed
> throughout the API as well.
>
> 2. JNode's Command API - I have seen people tout JNode's as being
> better than GShell... but it is LGPL but JNode have never really
> advertised their code base as a collection of reusable components.
>
> Both of these are trying to solve the same problem of making a generic
> API where commands, help, completion and everything are considered. I
> would say JNode's is marginally better because if its notion of
> argument types.
>
> I guess what I'm wondering is, was there a particular reason Felix's
> is the way it is, or is it because the codebase was pull in from
> wherever and nobody has really used it intensively yet?
>
>
> TX
>
> P.S. And on a side-note... I have been wondering how to get
> user-level access control for commands, to control who can do what.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Le respect commence par celui de l'environnement