You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Kirchev, Lazar" <l....@sap.com> on 2010/09/08 11:47:51 UTC
Implementation of the last APIs, added to RFC 147, in GoGo
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.
Thnaks and regards,
Lazar Kirchev
RE: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Kirchev, Lazar" <l....@sap.com>.
>> 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:heavy@ungoverned.org]
> Sent: Wednesday, September 08, 2010 4:20 PM
> To: users@felix.apache.org
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by Guillaume Nodet <gn...@gmail.com>.
Jline is BSD licensed, so it should be compatible with EPL afaik.
If not , I'm quite convinced it might be possible to ask for a license
change if needed.
However, if the problem comes from IP, things might be different...
On Thu, Sep 16, 2010 at 08:54, Kirchev, Lazar <l....@sap.com> wrote:
> If you plan to include command-line editing in gogo, if you are interested we may
> contribute what we have written so far in this direction.
>
> Regarding the jline library - we cannot use it in Equinox because of licensing issues.
>
> Regards,
> Lazar
>
> -----Original Message-----
> From: Derek Baum [mailto:derek.baum@paremus.com]
> Sent: Friday, September 10, 2010 6:22 PM
> To: users
> Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo
>
> On 10 September 2010 15:38, Kirchev, Lazar <l....@sap.com> wrote:
>
> 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:derek.baum@paremus.com]
>> 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 <l....@sap.com> 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:derek.baum@paremus.com]
>> > 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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
>> > >> Sent: Wednesday, September 08, 2010 4:20 PM
>> > >> To: users@felix.apache.org
>> > >> 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: users-unsubscribe@felix.apache.org
>> > >> For additional commands, e-mail: users-help@felix.apache.org
>> > >>
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > >> For additional commands, e-mail: users-help@felix.apache.org
>> > >>
>> > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > > For additional commands, e-mail: users-help@felix.apache.org
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Kirchev, Lazar" <l....@sap.com>.
If you plan to include command-line editing in gogo, if you are interested we may
contribute what we have written so far in this direction.
Regarding the jline library - we cannot use it in Equinox because of licensing issues.
Regards,
Lazar
-----Original Message-----
From: Derek Baum [mailto:derek.baum@paremus.com]
Sent: Friday, September 10, 2010 6:22 PM
To: users
Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo
On 10 September 2010 15:38, Kirchev, Lazar <l....@sap.com> wrote:
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:derek.baum@paremus.com]
> 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 <l....@sap.com> 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:derek.baum@paremus.com]
> > 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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
> > >> Sent: Wednesday, September 08, 2010 4:20 PM
> > >> To: users@felix.apache.org
> > >> 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: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by Derek Baum <de...@paremus.com>.
On 10 September 2010 15:38, Kirchev, Lazar <l....@sap.com> 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:derek.baum@paremus.com]
> 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 <l....@sap.com> 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:derek.baum@paremus.com]
> > 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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
> > >> Sent: Wednesday, September 08, 2010 4:20 PM
> > >> To: users@felix.apache.org
> > >> 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: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Kirchev, Lazar" <l....@sap.com>.
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.
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.
Lazar
-----Original Message-----
From: Derek Baum [mailto:derek.baum@paremus.com]
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 <l....@sap.com> 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:derek.baum@paremus.com]
> 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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
> >> Sent: Wednesday, September 08, 2010 4:20 PM
> >> To: users@felix.apache.org
> >> 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: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Kirchev, Lazar" <l....@sap.com>.
Thanks Guillaume,
I will definitely check the implementation.
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: Friday, September 10, 2010 4:54 PM
To: users@felix.apache.org
Subject: Re: Implementation of the last APIs, added to RFC 147, in GoGo
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 <de...@paremus.com> 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 <l....@sap.com> 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:derek.baum@paremus.com]
>> 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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
>> >> Sent: Wednesday, September 08, 2010 4:20 PM
>> >> To: users@felix.apache.org
>> >> 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: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <de...@paremus.com> 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 <l....@sap.com> 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:derek.baum@paremus.com]
>> 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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
>> >> Sent: Wednesday, September 08, 2010 4:20 PM
>> >> To: users@felix.apache.org
>> >> 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: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by Derek Baum <de...@paremus.com>.
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 <l....@sap.com> 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:derek.baum@paremus.com]
> 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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
> >> Sent: Wednesday, September 08, 2010 4:20 PM
> >> To: users@felix.apache.org
> >> 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: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Kirchev, Lazar" <l....@sap.com>.
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:derek.baum@paremus.com]
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 <he...@ungoverned.org> 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:heavy@ungoverned.org]
>> Sent: Wednesday, September 08, 2010 4:20 PM
>> To: users@felix.apache.org
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by Derek Baum <de...@paremus.com>.
On 9 September 2010 14:28, Richard S. Hall <he...@ungoverned.org> 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:heavy@ungoverned.org]
>> Sent: Wednesday, September 08, 2010 4:20 PM
>> To: users@felix.apache.org
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
> 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:heavy@ungoverned.org]
> Sent: Wednesday, September 08, 2010 4:20 PM
> To: users@felix.apache.org
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Kirchev, Lazar" <l....@sap.com>.
Hi Richard,
Thanks for the answer.
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.
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.
Regards,
Lazar
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Wednesday, September 08, 2010 4:20 PM
To: users@felix.apache.org
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Implementation of the last APIs, added to RFC 147, in GoGo
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org