You could also have a look at Karaf which already has the kind of console you're trying to build with history, enhanced tab completion, colorized output ...
On Fri, Sep 10, 2010 at 15:50, Derek Baum <[email protected]> wrote: > 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] >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
