On 5/12/10 6:54, Derek Baum wrote:
> 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.
The current commands in the osgi: scope in gogo include:
methods on Bundle
methods on BundleContext
methods on PackageAdmin, StartLevel and PermissionAdmin, if
service available
built-in procedural commands (each, if, tac, new)
example commands (cat, echo, grep, etc)
Richard Hall has asked me to reduce the default commands
registered in the gogo runtime to a minimum. The gogo console or other
users of the gogo runtime, can then easily register other commands as
required.
I think the minimum from the above is just the methods on
BundleContext, and the procedural commands, as this then allows the
other commands to be added, if required, using a script:
Personally, I don't think we should even spec that. I don't think there
should be any commands from registered objects by default because this
runtime is general enough to be used as a shell outside of an OSGi
context. We could potentially make adding this "default command"
configurable. But even then, I'd prefer the default to be disabled.
Likewise, for built in commands we'd likely be best focusing on the
essential general commands we need irrespective of OSGi-specific commands.
-> richard
% addcommand osgi (bundle 0)
% service = {
refs = osgi:serviceReferences $1 null
if {$refs} {osgi:getService ($refs 0)}
}
paclass = (bundle 0) loadclass
org.osgi.service.packageadmin.PackageAdmin
paservice = service ($paclass name)
% addcommand osgi $paservice $paclass
I include 'tac' and 'new' in the group of 'built-in' commands,
because the RFC explicitly describes 'tac' as the way to direct output
to a file and 'new' should leverage the same argument coercion used
for method invocation.
'addcommand' is currently in the shell: scope. I think this should
be moved to the osgi: scope and defined in the RFC.
Derek
On 11 May 2010 19:49, Peter Kriens <[email protected]
<mailto:[email protected]>> 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
