I am updated RFC 147 and prepare it for the meeting next week. I've got the
following feedback so far:
FELIX-1526 Replace <> embedded execution with (). Originally the () were used
for filters. I am ok in making this change and not directly supporting filters.
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
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.
#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.
#49 Provide access to the variables. Makes a lot of sense.
#49 Allow removal of variables. Maybe we should use have a Map<String,Object>
getVariables method.
#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.
#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.
#52 commands in osgi: scope need to be well defined. They're currently defined
as the methods on the BundleContext ... Will work on this.
#51 Define command search order. Makes sense to add a PATH variable of type
String[].
#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.
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
