On 10 September 2010 15:38, Kirchev, Lazar <[email protected]> wrote:
> But as you noted yourself, the provider, when calls create session, should > be aware of the > InputStreamProxy. This is what I mean by change in the code. In the example > with the > telnet server in GoGo, it calls createSession() with the socket > input/output streams and > I cannot pass a proxy without modifying its code. > This could be solved if a setInput() method was added to CommandSession; Although Peter originally rejected this, your use case is further evidence that this would be useful. > > Actually, in this particular case the editing includes handling of > backspace, delete, arrows and some > other keys. Isn't it possible such editing to be included in the GoGo > shell, > where the streams content is actually read? It is useful, and if some > provider over GoGo > implements his own editing, the symbols which the editing processor handles > will never > reach the GoGo shell - they will be already handled and removed from the > stream content, > so the shell will not handle them. In the case when no editing is provided, > it will come automatically with the GoGo shell. > However, if you think that such feature is inappropriate for the shell, I > will stick to > the other option. > I agree that command-line editing would be useful in gogo. I expect that gogo will provide or integrate with a command line editing provider in the next few months. Until then you can see how Karaf have provided command-line editing using jline. Regards, Derek > > Lazar > > -----Original Message----- > From: Derek Baum [mailto:[email protected]] > Sent: Friday, September 10, 2010 4:51 PM > To: users > Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
