felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [gogo] Advanced commands / console
Date Sat, 04 Jul 2009 16:28:16 GMT
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.
Thoughts ?

On Sat, Jul 4, 2009 at 16:14, Richard S. Hall<heavy@ungoverned.org> 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<gnodet@gmail.com>  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<heavy@ungoverned.org>
>>>  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<gnodet@gmail.com>
>>>>>  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

Mime
View raw message