[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ptp-dev] Re: remote tools
|
Hi Daniel,
Thanks for your reply. I'm sure that PTP is using remote tools in a
way that was not originally foreseen. The PTP remote model is somewhat
different to remote tools, so I'll describe it in more detail. The
basic idea is to provide a high-level abstraction of remote activities
that are then implemented by underlying remote subsystems. The two
remote subsystems that PTP is currently targeting are the remote tools
and the remote system explorer (RSE). The high-level abstraction that
PTP provides is aimed at supplying remote functionality for Eclipse
plugins, rather than for the end-user (as is RSE's goal). The main
components of the abstraction are:
1. Connections. These are the basic mechanism for communication with a
remote system. A connection is an abstraction of an underlying
communications channel, and has the notion of being open or closed.
Operations can only be performed on open connections. There is no
particular requirement that a connection use ssh, or any other
protocol, however it does need to support file and process operations
(below).
2. Connection Manager. A connection manager is responsible for
managing connections. In this context, management means creation and
deletion of connections.
3. File Manager. A file manager is responsible for file-type
operations on remote resources, and it's main function is to unify
connections with the platform EFS interfaces. That is, it allows EFS
file operations over a remote connection that is managed by a
connection manager. It also provides a UI component for browsing
remote files and directories.
4. Process Builder. A process builder is a remote abstraction of the
Java ProcessBuilder class, except that the process is started on a
remote machine. The interface also supports asynchronous process
execution.
You will note that this abstraction has a lot of overlap with both the
remote tools core interfaces, and the remote tools environment job
interfaces. In fact many of the names I have chosen for the interfaces
are the same as yours (by accident). I definitely see an opportunity
to unify the two in the future, and I really like your remote job
model. I would like to expose that at the abstraction level at some
point also. I think the first requirement though, is to just get the
two working together.
Now, to address your comments in more detail. I don't have any
particular need for an IRemoteConnection, other than as a means of
obtaining an IRemoteExecutionManager. If there was an alternate
mechanism for this then I would be happy. Un-deprecating
getConnection() simply seemed the easiest way to do this. Although I
didn't say it in my previous email, I had already discovered that an
IRemoteExecutionManager was only valid for the life of a job. To get
around this, I start a dummy job when the connection is "opened" (or
create is called on ITargetControl in your terminology). The job
persists until the connection is "closed" (kill is called). However
this code is pretty convoluted and, I imagine, brittle. A simpler and
more robust mechanism would be preferable.
Regards,
Greg
On Dec 18, 2007, at 4:48 PM, Daniel Felix Ferber wrote:
Hi Greg,
About the first question, as we talked on sametime, I am going to
attach patches for two bugs. The first enables remote port
forwarding. The second fixes some minor issues that we found recently.
As RemoteTools was originally designed, one should not handle
IRemoteConnection directly, but instead obtain an
IRemoteExecutionManager. It is supposed that there is a class that
manages the connection (as generic host does) and this class has an
internal logic to create an IRemoteExecutionManager to be used by
other objects. This allows having several concurrent jobs sharing
one single connection, each job with its own execution manager.
The getConnection() was used as a workaround in very early alpha
versions of Cell IDE, because ITargetControl was not completely
implemented. By using getConnection(), the programmer might bypass
ITargetControl by taking over control of the IRemoteConnection.
The reason why ITargetControl does not offer the getConnection()
method directly is that ITargetControl requires to have control over
the execution of a remote job. The ITargetControl supposes that,
once connected, the user may issue one or more potentially
concurrent jobs at any time. A job is a sequence of operations on
the remote host that belong together (like, deploying, executing and
cleaning an application on the remote host) and that are executed on
a separate thread. If the user wants to disconnect a target, then
the target must be aware of ongoing jobs that need to be
interrupted. The target also needs to wait until all jobs have
finished before disconnecting, or an interrupted job might leave the
remote host in an inconsistent state or fail to clean up. When a job
is interrupted, any operation on the execution manager will raise
and CancelException.
In order to implement correctly an operation on the generic host,
one creates an instance of an ITargetJob that implements the
operation, adds it to the generic host by calling
ITargetControl.startJob() and waits until the ITargetJob finishes
(the thread waits and is notified by the ITargetJob) or lets the job
run in background. The current launcher on remote tools was
implemented as a ITargetJob.
One should not store the IRemoteExecutionManager passed to the
ITargetJob, nor reuse this IRemoteExecutionManager after the job has
finished, because the resources used by the execution manager will
not exist anymore. Creating an ITargetJob just to get the reference
of the IRemoteExecutionManager will behave unexpectedly, since it
was not how RemoteTools was designed to work.
In my oppinion, we really should _not_ un-deprecate the
getConnection() since it would break the design of ITargetControl.
Would you really need to get the IRemoteConnection? This might be a
need that we have not foreseen on remote tools. Or are you just
looking how to get access to a IRemoteExecutionManager? If I
remember correctly, there is no relevant method on IRemoteConnection
to be called after the connections was established.
In ordre to accommodate PTPs needs, my suggestion would be consider
other strategies that require less effort for the programmer to get
the IRemoteExecutionManager. One alternative that comes into my mind
is having ITargetControl to create a registered
IRemoteExecutionManager to be used by the application (eg. used by a
GUI), and then requiring the application to unregister
IRemoteExecutionManager when not used anymore. Of course, other
solutions are welcome, I would really appreciate your comments!
Best Regards,
Daniel Felix Ferber
Greg Watson escreveu:
Danial,
I have a couple of questions about the remote tools:
1. Currently the createTunnel() methods only seem to allow the
creation of local port forwarding (i.e. where connections to the
local port are forwarded to the remote port) and not remote port
forwarding (where connections to a port on a remote machine are
forwarded to the local port). Do you have any plans to add the
latter, or would you object if I did?
2. I'm accessing the generic host functionality through the
environment interface ITargetControl, but I really need to get at
the IRemoteConnection (and ultimately IRemoteExecutionManager).
Unfortunately the getConnection() method has been deprecated, so I
have to resort to launching a dummy job (that gets passed the
IRemoteExecutionManager) in order to get this interface. What was
the reason that this interface was deprecated? Would it be possible
to have it un-deprecated?
Thanks,
Greg
