Community
Participate
Working Groups
Currently, only SSH supports a Terminal subsystem, explicitly declared in the rse.terminals.ssh plugin. I'd like to see the rse.subsystems.terminals.core / rse.terminals.ui plugin declare a generic Terminal Subsystem, that can be registered against any SystemType (by "pulling" the subsystem in from the SystemType), and that works as soon as any of the existing other subsystems below the IHost has an IService that adapts to ITerminalService. Essentially, I'd like to see the following at runtime: ITerminalService tsvc = null; for ISubSystem subsys : host.getSubSystems() { IService svc = subsys.getSubSystemConfiguration().getService(host); if (svc!=null) { tsvc = (ITerminalService)svc.getAdapter(ITerminalService.class); if (tsvc!=null) { break; } } } Doing this, we should be able to have a generic Terminal Subsystem on top of any other contributed subsystem, very much like the Linux Shell Processes Subsystem. Going further, it might make sense to make SshFileService adapt to SshTerminalService, such that the generic terminal service can be contributed as soon as there is an ssh file service.
(In reply to comment #0) > Doing this, we should be able to have a generic Terminal Subsystem on top of > any other contributed subsystem, very much like the Linux Shell Processes > Subsystem. Do we have any service now that adapts to ITerminalService?
Not yet, and I'd prefer doing it the other way round: Convert TelnetService into an ITerminalService since that's the smaller but more flexible API; then, have the TelnetTerminalService adapt to an IShellService via the generic factory. As a result, telnet should be able to run in both terminal and shell.
Created attachment 113308 [details] first draft It works fine except one thing: it throws NPE during new connection creation. The reason for this is that at that moment we don't have real host and thus have no subsystems, so when we're trying to find a service which adapts to ITerminalService we're always getting null, so cannot get name and description from it in ServiceServiceElement.
(In reply to comment #3) > The reason for this is that at that moment we don't have real host and > thus have no subsystems, so when we're trying to find a service which > adapts to ITerminalService we're always getting null, so cannot get name > and description from it in ServiceServiceElement. DaveM do you think you could help with this?
Created attachment 113526 [details] patch with a few changes I played around with this a bit and managed to get something to work although I still run into problems. In particular, if on creation, no service exists that adapts to ITerminalService then we hit a stack overflow. Anyway, my hope is that this patch will help take this further.
Thanks a lot, Dave! I also wanted to ask: what is desired behaviour in case when there's no service that adapts to ITerminalService? (In reply to comment #5) > Created an attachment (id=113526) [details] > patch with a few changes > > I played around with this a bit and managed to get something to work although I > still run into problems. In particular, if on creation, no service exists that > adapts to ITerminalService then we hit a stack overflow. Anyway, my hope is > that this patch will help take this further. >
(In reply to comment #6) > what is desired behaviour in case when there's no service > that adapts to ITerminalService? Ideally, the subsystem should not be available for selection (since it could not ever be instantiated). But I do not think it is any problem if this check is not made. Our SystemTypes are currently statically associating subsystems with a SystemType. So the programmer of a SystemType is respeonsible for selecting a "good mix" of subsystems. That is, the programmer is repsonsible for adding the "Generic Terminal" subsystem *only* if she also adds some other subsystem that provides a Service which can adapt to an ITerminalService. In the future, we might want to revise this when the selection of subsystems becomes more dynamic. But for now, I think we're good to go with the static association.
(In reply to comment #7) > (In reply to comment #6) > > what is desired behaviour in case when there's no service > > that adapts to ITerminalService? > > Ideally, the subsystem should not be available for selection (since it could > not ever be instantiated). > > But I do not think it is any problem if this check is not made. Our SystemTypes > are currently statically associating subsystems with a SystemType. So the > programmer of a SystemType is respeonsible for selecting a "good mix" of > subsystems. That is, the programmer is repsonsible for adding the "Generic > Terminal" subsystem *only* if she also adds some other subsystem that provides > a Service which can adapt to an ITerminalService. > > In the future, we might want to revise this when the selection of subsystems > becomes more dynamic. But for now, I think we're good to go with the static > association. > I just want to clarify something in case it's not obvious here. The problem I ran into is that even though I have the choice of using ssh for shells, I can still pick something else (like dstore or ftp). If none of the services I have chosen adapt to ITerminalService then the infinite recursion is hit. So to make this work via static association there has to be at least one subsystem that ONLY has a service that adapts to ITerminalService.
I see. The idea was to write an AdapterFactory that can adapt *any* IShellService to an ITerminalService, so then this should not be a problem any more?
(In reply to comment #9) > I see. The idea was to write an AdapterFactory that can adapt *any* > IShellService to an ITerminalService, so then this should not be a problem any > more? > If any IShellService can adapt to ITerminalService, then as long as there is a shell subsystem configuration for the system type in question, we should be good.
(In reply to comment #9) > I see. The idea was to write an AdapterFactory that can adapt *any* > IShellService to an ITerminalService, so then this should not be a problem any > more? Wasn't it vice versa? Each terminal service to shell service?
You are absolutely right Anna. I was (partially consciously) inexact here in order to try and explain the matters to Dave in a simpler way. Something I shouldn't do (and try not to do with my kids). So, the correct answer is: Right now, only SshShellService adapts to ITerminalService, but in the end we want each and every Shell Service to actually be implemented by an ITerminalService since that is easier to implement, more versatile and powerful in terms of the API. By writing a generic Adapter factory that can adapt any ITerminalService back to an IShellService, we'll get the original functionality back -- but more powerful and with less duplication of code. So, in the end, every shell service will be adaptable to an ITerminalService and the problem should be moot.
Code is checked in.
We should review the final API when verifying this with M4.
