felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject OSGi Shell
Date Tue, 11 May 2010 18:49:17 GMT
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
#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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message