>> 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. Fine, if you think this could be useful as a standard feature, I may propose it to the OSGi community for discussion to be included in the RFC. >> 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. Yes, I absolutely agree that the Equinox commands should be ported to RFC 147 commands, and that is exactly what we are going to do regarding the Equinox built-in commands. But in the sake of backwards compatibility we should support legacy Equinox commands that users have written themselves. We cannot assume that everyone who used the Equinox API for shell commands will port the commands to RFC 147. Lazar > 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]
