Re: [dsdp-tm-dev] "Run a command" functionality

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

> thanks for the guidance, as well as providing related issues that must be
> considered. Now that I understand this feature is in general welcome,
>  I'll work with my management to schedule actual work on this.

Welcome.

In terms of API, I could imagine that using the well-known Java Process API
as we do today in HostShellProcessAdapter is actually not a bad idea; it provides
access to the target process Streams, as well as the exitValue, and allows killing
the remote with destroy(). Check if you find that API good enough as a consumer.

If yes, then only the implementation needs to be improved for your particular
use-case, i.e. return an exitValue and potentially improve performance by
re-using the same channel for multiple invocations if desired. And you'll want 
to make it more accessible (eg Factory Method instead of new... see also below).

In terms of SPI (service provider interface, for plugging in different shell interpreters)
You'll see what you need, and have yourself inspired by James' work.

Finally, if the agent case is deemed interesting, and you want the feature to be
more easily accessible, you'll probably want to add new API such that a 
SubSystem can return the Process object directly without the extra Shell.
For  instance:

   interface IRemoteCmdSubSystem2 extends IRemoteCmdSubSystem {
       Process execCommand(...); // inspired by Java Runtime.exec()
   }

Down the road we'll see whether it makes sense to have 2 different API 
methods, one for re-using an existing channel and one for opening a new
channel for the command. Though re-using an existing channel is likely more
interesting in the non-agent case where setting up a new session / channel
is expensive.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6