My solution does not involve modifying telnet or ssh provider code. Instead a new gogo shell command is provided to replace the input stream of a session with a wrapped editing stream _after_ createSession() is called.
Derek On 10 September 2010 07:14, Kirchev, Lazar <[email protected]> wrote: > Actually currently I implemented this in a way similar to the one suggested > by you - > I implement my own telnet command, and wrap the telnet streams before > passing them to > createSession(). In my particular case it is a solution, but made me think > about the more general > case of a provider, which does not implement editing. For example, the > simple telnet server, > built in GoGo. It is not possible to add editing capabilities > transparently, without > modifying the code. > > Regards, > Lazar > > -----Original Message----- > From: Derek Baum [mailto:[email protected]] > Sent: Friday, September 10, 2010 7:55 AM > To: users > Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
