On 9/9/10 4:41, Kirchev, Lazar wrote:
Regarding the shell, I have another question. Currently we are working on
adopting GoGo as the shell in Equinox. I am writing some features over GoGo to
provide command line editing supportability, e.g., for telnet input. I
implement separately the handling of the telnet protocol and the editing of the
input (which includes processing of backspace, dell, arrows, history, etc.).
The editing processor wraps the telnet streams and passes the wrapped streams
to the createSession() method. In this way, the telnet handler provider should
be aware of the editing processor and use it before creating a session. But in
general, this may not be the case. A provider may provide, for example, a
bundle with ssh support, a web console, etc. If the provider has no notion of
the existence of the editor, he/she will not use this functionality. So is it
possible such wrapping to be done by the CommandProcessor, when creating the
CommandSession? If GoGo provides an interface for stream wrapping, the
CommandProcessor may check when creating the session if there is a registered
service, implementing this interface, and if there is such a service, it may
wrap the streams so that the editing functionality becomes available
transparently for the provider.
This sounds like a feature request and seems reasonable. Not sure if
this is something that should be discussed as a Gogo-specific feature or
a potential standard feature. Perhaps Derek has a comment.
And I have a question regarding getting commands help. Currently we use an
adaptor for the equinox commands, so that they become visible in GoGo. The
adapter registers the osgi.command.function property with a list containing all
names of the available equinox commands. Actually it does not provide methods
for each of them, but in a main() method decides which one should be called
(the adaptor cannot have hardcoded methods for all commands, because it is not
known in advance what commands the user bundles will register). The problem is
that GoGo help command does not list the method names, provided by the adaptor
in the osgi.command.function (because it checks for each of them if it is
provided as a public method of the adaptor class). Is this a bug, or intended
behavior? According to the RFC, the command provider should have public methods
for the provided commands. I guess this is the reason for the behavior of GoGo
help command, but in the particular case of the this is not feasible.
Yeah, the method-per-command approach is the recommended approach and
the annotations were made to support that approach. We'll have to
investigate if there is something we can do here as a Gogo-specific
workaround, but the whole main() approach is purely a legacy crutch to
help people migrate old commands to Gogo, so it is not something we
intend to encourage people to use. In the long run, Equinox commands
should be ported.
In the short term, we can try to find a way to display more
info...remember "help" is just a command, so we can always have an
alternate implementation.
-> richard
Regards,
Lazar
-----Original Message-----
From: Richard S. Hall [mailto:[email protected]]
Sent: Wednesday, September 08, 2010 4:20 PM
To: [email protected]
Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo
On 9/8/10 5:47, Kirchev, Lazar wrote:
Hello,
I would like to ask when the last additions to RFC 147 may be expected in the
GoGo implementation? I am particularly interested in the Scope and Terminal
APIs. I am writing some shell code which can make use of these features. I
checked the jira, but couldn't find any issues related with this.
We need to have some discussion about how to deal such provisional OSGi
APIs, once we do that, we just need to find the time to do it.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
