RE: [dsdp-tm-dev] Evaluation of RSE for Remote Server Support in PTP

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

Hello Tianchao,

thanks very much for your comments. See some more inlined:

> Based on the categorization of placement(Local, Remote, 
> Hybrid), you can
> have different actions to achieve what you want. And 
> replication is one
> of them, that can be applied to Local and Hybrid scenario.

In case of replication, it is not totally clear whether you 
would consider placement as being local, hybrid or remote
- since the workspace physically resides both locally and
remotely.
I guess it depends on where you consider the "master" of 
your copied workspace to reside. You can have various schemes:

  * master remote - every local modification is copied to 
    remote instantly. In case of conflict, remote wins.
  * master local - modifications are kept local until the
    next build. In case of conflict, remote is overwritten.
  * hybrid - modifications can happen locally and remotely.
    With a smart reconciliation strategy during synchronization.

Perhaps this is just another verbal expression for those 
scenarios that you already listed. But I find it easier to
think about the master of replication.
In terms of the replication strategy, you can also have various
schemes:

  * transparent replication - files are accessed locally or
    remotely as needed, access time is nondeterministic
  * explicit replication - user chooses what and when to 
    replicate, access time is deterministic

I feel that these various schemes warrant thinking about 
replication, and not just considering it an implementation 
detail of transparent access.

> accept it. However, EFS has local caches and you only need to transfer
> the 'remotely'  file for only once. 

I just browsed the EFS APIs quickly, but when I got the Javadoc
right, the EFS cache is valid only during one Eclipse session.
Local cached files will be deleted after that session, so on the
next Workbench startup you'll need to transfer files again.

RSE has a persistent cache that can be cleared explicitly. Since
RSE can serve as an EFS provider, you can consider persistent 
caching a configuration option for EFS.

> It is good that you can provide
> EFS for the remote machine, and actually I'm very willing to use such
> remote file systems (though I'm meeting some bugs, ref. bug #143023).

Thanks, we appreciate your help and testing a lot.

> Merely integration with EFS is however not the best solution. 
> There are
> a lot overlapping between the File subsystem and the EFS. I find no
> reason why you can't use EFS API to replace your file subsystem.

We need to think more about it. The RSE Files API is a lot simpler 
than the EFS API. And there are some existing IBM clients that 
will want to continue using the existing API.

But we continue thinking about it.
For now, we've started a comparison and discussion page on 
http://wiki.eclipse.org/index.php/Eclipse_File_Service_APIs_Compared
Feel free to add your thoughts to the "talk" page there.

I could imagine that RSE would eventually accept EFS providers
on its Files backend. The value-add of RSE would then be
  * persistent caching
  * access to remote resources outside the workspace
  * connection and filter management
    - selection of channels
    - password/keyring management
  * association of shell and other channels with the files channel

> samething with EFS, but of course at a little more cost. However, we
> automatically has all the advantage of the Eclipse - we can apply any
> type of search on the remote project (can you do Java search 
> with remote search?)

It's good that the user can choose, i.e. we provide an abstract
remote file system for transparent access (slow) AND an explicit
remote file system for fast text search.

> I haven't tried datastore up to now. But anyway, you need to start a
> custom server on the remote machine.

True - but the remote server gives you also more control over the
remote machine and allows performing operations (like remote search)
with little data transfer. The custom server can be launched on a 
per-user basis e.g. 
  ssh remote -l username perl /opt/RSE/server.pl

> Sure. We'd like to collaborate and contribute to RSE. RSE is good, but
> needs improvement. 

Cool. Let's go for it :-)

Cheers,
Martin
--
Martin Oberhuber - WindRiver, Austria
+43(662)457915-85