Hi Richard, Thanks for the answer.
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. 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. 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]
