Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] PTP remote abstraction layer

Greg
A few questions
1) Are you planning to implement the full IFileStore interface or just the 
methods to transfer files between local and remote system? In particular, 
I'm thinking of the  openInputStream and openOutputStream methods which 
would be useful in cases where I wouldn't want to transfer the entire file 
across the connection before using it, since the receiving side may not 
have space to store the whole file or I don't want to wait for the file to 
be completely transferred before I read it.
2) This implies to me some support on the remote system to handle the 
requests sent from the local node. Is this something that my proxy would 
need to handle or is there another layer (RSE?) that provides that 
support?
3) Is the intent of the IFileStore to provide a means to move, say data 
files generated by the run of some performance analysis tool, from the 
remote system to the local system for viewing?
Thanks
Dave



Greg Watson <g.watson@xxxxxxxxxxxx> 
Sent by: ptp-dev-bounces@xxxxxxxxxxx
07/09/2007 02:36 PM
Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] PTP remote abstraction layer






I'm still working on the details, but here's the current plan:

1. The existing 
org.eclipse.ptp.core.AbstractProxyRuntimeClient.startupProxyServer() 
and shutdownProxyServer() will become abstract methods.

2. I'll provide an implementation of these methods in 
org.eclipse.ptp.remote.AbstractRemoteProxyRuntimeClient.

3. RM's that want to use remote services (ORTE, LSF, MPICH2, etc.) 
will extend this class instead of extending the existing 
AbstractProxyRuntimeClient.

4. I'll also provide an abstract wizard page that an RM can extend to 
select a remote services provider, select/create a connection, etc.

The remote abstraction layer provides the following:

1. A remote services abstraction for the following services:

   a. Remote process execution (IRemoteProcess and 
IRemoteProcessBuilder)

   b. Remote file management (IRemoteFileManagement)

   c. Remote connection management (IRemoteConnectionManagement)

2. A default implementation for local-only services.

To add support for a particular remote system, a plugin must extend 
the org.eclipse.ptp.remote.remoteServices extension point. I've 
provided a plugin that does this for RSE. Basically this plugin must 
map the abstraction layer to the actual remote implementation

Let me know if you need any more information.

Greg

On Jul 9, 2007, at 10:48 AM, Randy M. Roberts wrote:

> Greg,
>
> It looks like all of this has been created in
> org.eclipse.ptp.remote.  Could you give me a run-through
> on how it hooks into the RM system?
>
> R^2
>
> On Wed, 2007-06-27 at 13:52 -0600, Greg Watson wrote:
>> Here are some requirements for an initial remote abstraction layer
>> for PTP:
>>
>> 1. Remote command execution. Execute an arbitrary command on a remote
>> system. The remote command should extend the Process class, making
>> stdin, stdout and stderr available via separate Streams.
>>
>> Suggested interface:
>>
>> public class RemoteProcess extends Process;
>>
>> RemoteProcess p = Remote.exec(IRemoteConnection conn, String cmd,
>> String[] args);
>>
>> 2. Connection management. This would provide functionality for
>> managing (adding/removing, etc.) IRemoteConnection's that contain the
>> hostname, username, password and system type (SSH, etc.) for the
>> connection.
>>
>> 3. Remote file browser. This would provide the equivalent
>> functionality to FileDialog on the remote machine. It is needed to
>> allow the user to browse for the proxy executable if necessary.
>>
>> Suggested interface:
>>
>> public class RemoteFileDialog extends FileDialog;
>>
>> 4. Remote file transfer. Allows the transfer of files between local/
>> remote and remote/remote connections.
>>
>> Suggested interface:
>>
>> This should just use the IFileStore interface.
>>
>> _______________________________________________
>> ptp-dev mailing list
>> ptp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev




Back to the top