On 9 September 2010 14:28, Richard S. Hall <[email protected]> wrote:
> 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. It may not always be desirable for the CommandProcessor to wrap streams as you suggest. Consider a telnet or ssh bundle that is unaware of your editing processor and that implements its own editing. It would not want to be automatically wrapped with some other editing support. It is however possible to wrap streams to achieve the decoupling that you want using the current version of gogo. You could provide a gogo command to enable command-line editing in the current session. This command would just need to call CommandSession.setInput(editingStream), to replace the original InputStream used in CommandProcessor.createSession(). (The gogo shell could also be changed to that it automatically enabled command-line editing, according to the users preference). The only problem is that CommandSession does not have a setInput() method! Item #5 in this bug request suggested adding such a method: https://www.osgi.org/bugzilla/show_bug.cgi?id=49 5. InputStream setInput(InputStream in); When adding a ReadLine history/completion facility to an existing session, it is necessary to change the session input source. Current this can only be done at session creation. But Peter deemed it unnecessary: > 8. #49.5 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. This means that a known InputStreamProxy must be passed to CommandProcessor.createSession() so that setInput() can be achieved by casting CommandSession.getKeyboard() to InputStreamProxy and calling the appropriate method. I was OK with this, but in your case it breaks the decoupling you wanted as the Telnet processor must know to use an InputStreamProxy. Regards, Derek > > > 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] > >
