On 4 Jul 2009, at 17:28, Guillaume Nodet <[email protected]> wrote:
I guess there are two different ways to name command:
* either have a somewhat consistent command name (with lots of
commands having the same name) and disambiguating those using scope
* try to minimize commands with the same name to avoid having to
disambiguate them
In karaf, we mostly use the first way:
obr/list
obr/addUrl
osgi/list
features/list
features/addUrl
admin/list
I don't see this way is better than the other. But it may be a bit
harder to minimize conflicts without having cumbersome command names.
What we have in Karaf is a concept of alias and links, so that we can
have both at the same time: explicit command names like
features/list (scope = features, name = list) but we can define an
alias named "fl" for example ...
I guess we can have both of best world this way.
So a /really/ powerful part of the rfc 132 TSL language is support for
closures. These can be used to do the job of aliases in trivial cases
and much more powerful things if you put your mind to it ;)
For example you could define a closure
# fl = { features:list }
# fl // same as typing features:list
Now consider that closures support $ parameters...
# ins = { osgi:install $1 } // defines a closure
# ins file:somebundle.jar // same as typing osgi:install
file:somebundle.jar
Thoughts ?
On Sat, Jul 4, 2009 at 16:14, Richard S. Hall<[email protected]>
wrote:
On 7/4/09 2:58 AM, David Savage wrote:
Yep that's how it works, Derek's fixes make scope a variable which
defines a ":" delimited set of scopes to search (in order) for
commands.
So consider if there were several commands registered in different
scopes:
foo:foo
bar:foo
bar:bar
baz:baz
If you were to enter (into the console)
SCOPE=foo:bar:*
Then later when you type "foo" you'd get foo:foo and when you typed
"bar" you'd get bar:bar. The wild card allows for searching all
other
known scopes, so when you type "baz" you'd get baz:baz. If there
were
another command bam:baz then I believe the * picks the command
installed first?
This is much like setting the PATH variable in standard shells so
you
get a known version of "ls" vs some random "ls" binary on your file
system.
I don't have an issue with have a PATH-like concept, but by default
all
"scopes" should be on the path unless otherwise specified. I don't
want to
be forced into dynamically managing my PATH variable for every set of
commands I want to use.
Of course, this has implications, because it means you are either
do not
generally reuse the same command name for different purposes or use
the
command/subcommand approach (like with "obr list").
In the latter case, it could be convenient, I suppose if "obr list"
were
treated as a scope and command separated by a space, otherwise obr
would end
up having a scope and then a command/subcommand.
-> richard
Regards,
Dave
On Sat, Jul 4, 2009 at 7:22 AM, Guillaume Nodet<[email protected]>
wrote:
Not necesserally sub-shells, but the scope concept is already
part of
gogo.
Each command already has a scope. For example, the bundleContext
methods are defined in the "osgi" scope so you can access those
using:
$ bundles
or
$ osgi:bundles
This allow disambiguating otherwise ambiguous commands.
Derek also fixed some bugs around that.
I'm not sure yet, but I think you might change the default scope
using
$ SCOPE = osgi
Hven't tried that though.
On Fri, Jul 3, 2009 at 23:46, Richard S. Hall<[email protected]>
wrote:
On 7/3/09 12:10 PM, Guillaume Nodet wrote:
I've checked in the prototype into gogo for further discussion.
See https://svn.apache.org/repos/asf/felix/trunk/gogo/gogo.commands/
Note, I renamed this to:
https://svn.apache.org/repos/asf/felix/trunk/gogo/commands/
I realized that I had the naming incorrect, even though I
changed it a
couple of days ago.
I've also fixed the gogo parser a bit as to be slightly more
leniant
when parsing the first argument (so that '/' or '-' could be
part of
the first argument).
Are you imaging the Karaf "sub-shell" concept being part of
Gogo? I
cannot
say I am a fan of that concept.
-> richard
Feedback welcome !
On Thu, Jul 2, 2009 at 08:24, Guillaume Nodet<[email protected]>
wrote:
For Karaf, I've been working on a prototype to be able to
support more
powerful commands in gogo.
The problem with the current way (i.e. one function == one
method) is
that it's quite difficult to
* display help for a command
* have optional arguments
So what I've done, and this would also benefit Karaf, is based
on what
gshell is doing for commands.
It's based on the following interfaces:
public interface Action
{
Object execute(CommandSession session) throws Exception;
}
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
public @interface Command
{
String scope();
String name();
String description() default "";
}
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.METHOD})
public @interface Argument
{
String name() default "VAL";
String description() default "";
boolean required() default false;
int index() default 0;
boolean multiValued() default false;
}
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.METHOD})
public @interface Option
{
String name();
String[] aliases() default {};
String description() default "";
boolean required() default false;
boolean multiValued() default false;
}
So a given command would look like:
@Command(scope = "my", name = "action")
public class MyAction implements Action {
@Option(name = "-s", aliases = { "--start" })
boolean start;
@Argument(name = "ids", required = true, multivalued = true)
List<Integer> ids;
public Object execute(CommandSession session) {
...
}
}
This action has to be wrapped inside a command (implementing the
Function interface) and which will be able to create a new
instance of
the action, parse the arguments, populate it, and call it.
In addition the wrapper will detect the use of "-h" or "--help"
arguments and compute / display the help on the console if
requested.
Curerntly, what I've done is leveraging blueprint, so I have a
custom
namespace (same as we had in karaf/gshell)
<command-bundle
xmlns="http://felix.apache.org/karaf/xmlns/gshell/v1.0.0";>
<command name="osgi/list">
<action
class="org.apache.felix.karaf.gshell.osgi.ListBundles">
<property name="blueprintListener"
ref="blueprintListener"/>
</action>
</command>
</command-bundle>
This will create a command and register it in the OSGi
registry so
that it will be available in the shell.
I haven't implemented completers yet, but that's next on my
todo list.
So the question is: should this be part of gogo or do we keep
that for
karaf ?
I have the same question for the console: I've started working
on an
advanced console (leveraging jline as we did in karaf / gshell).
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
