You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@felix.apache.org by Glyn Normington <gn...@vmware.com> on 2010/05/12 04:48:21 UTC

Re: [cpeg] OSGi Shell

I'm sorry I don't already know if these are already provided, but two critical requirements for the OSGi shell are:

1. tab completion of command syntax and parameters (such as bundle symbolic names and version numbers)
2. "up arrow" command recall (preferably filtered by any current input including that provided by tab completion)

Glyn
On 11 May 2010, at 19:49, Peter Kriens wrote:

I am updated RFC 147 and prepare it for the meeting next week. I've got the following feedback so far:

1. FELIX-1526 Replace <> embedded execution with (). Originally the () were used for filters. I am ok in making this change and not directly supporting filters.
2. FELIX-1473 When the first argument is a string, gogo considers it to be a command.
The problem is that it leads to unpredictible behavior when using variables

> $a length

Depending on the type of $a, it will either try to call a command named by the value of $a, or call the length method on the $a object. Felix added a . to force the interpretation to be a string. Guess (string $a) length would also work
3. FELIX-1536 Reverse priority of statement and pipe. Currently a; b | c pipes both and b through c. In unix this is different, it only pipes b through c. I think the current syntax is more logical but compatibility with unix is not irrelevant.
4. #49 Request to provide Set<String> getCommands. I suggest we create a CommandDescription that is returned. This description will provide sufficient info to not only finish the name of the command but also fill in parameters and show flags. See annotations later.
5. #49 Provide access to the variables. Makes a lot of sense.
6. #49 Allow removal of variables. Maybe we should use have a Map<String,Object> getVariables method.
7. #49 Add boolean isTty(InputStream in); boolean isTty(OutputStream out) so commands can adapt to interactive and piped. Not sure, needs discussion. I am not that charmed by commands adapting, that is why there are options.
8. #49 Add InputStream setInput(InputStream in) for history etc. I disagree. The request behavior can easily be gotten by proxying the input stream, I think. Lets try to keep it simple.
9. #52 commands in osgi: scope need to be well defined. They're currently defined as the methods on the BundleContext ... Will work on this.
10. #51 Define command search order. Makes sense to add a PATH variable of type String[].
11. #53 Command help. Adding the CommandDescriptor would help here.

Additionally, there is a development going on in Felix that made me want to add the following areas.

1. Richard and I played with annotations and the type conversion/method coercion. I like to add a new package and then define generic annotations for: Description + a special Parameter annotation. The description is logical, the Parameter will allow flags (-x), optionality, and will allow steering of type conversion. This made it clear to me that we need a type conversion package that can handle the requirements of Blueprint, TSH, and maybe even DS in the future. Type annotations can be provided to steer this conversion. It seems that this problem pops up in lots of places.

Any other items that should be taken care of?

Kind regards,

Peter Kriens

<ATT00001..txt>