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 Thu, 09 Jul 2009 15:22:49 GMT
Btw, I've fixed the $args parameter expansion a bit because it was
kinda useless, as it was always expanded to a List<Object> instead of
being appended to the list of existing arguments.
So now,
   fl = { features:list $args }
actually work as a real alias where all parameteres will be passed to
the function.
The previous behavior was bugged.   For example passing no arguments
lead to the features:list function  invoked with a single argument
being an empty list instead of no arguments.

On Sun, Jul 5, 2009 at 12:53, David Savage<david.savage@paremus.com> wrote:
> On 4 Jul 2009, at 17:28, Guillaume Nodet <gnodet@gmail.com> 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<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
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message