Comments from the Target Management Project / RSE:
In your 3 remote scenarios (local, remote, hybrid), I'm somewhat missing the "replicated" scenario which is assumed by many as the most common one (See bug 106176#c33).
Perhaps your "local" scenario means exactly this, but it became not quite evident from the document. Note that repliation can be done through a variety of means (including simple rsync on a commandline, which can be fine tuned e.g. not to sync remote *.o files which are not needed locally).
Perhaps your headline should simply read "Local Project, repliated". In the Roadmap, your points 3 and 4 (project export, project update") seem to go in this direction.
In your workflow list (code edit, remote build, debug etc) I was somewhat missing the "source analysis" step. Note that source parsers like the ones in JDT and CDT need to analyse the entire workspace. When you use a remote filesystem like EFS, each and every file needs to be transferred to local for this analysis step. "stat" calls need to be made for each and every file very often. The two ways around this are
- Allow a source parser to run remotely (I heard rumors that IBM is thinking about remote C/C++ parsing)
- Repliate the workspace efficiently and parse locally.
Since the first option seems to be way in the future, this is another argument for replicated workspaces and against fully remote workspaces.
- IBM Only is not true any more. We have actual source code contributions from Windriver, PalmSource and Symbian. The "com.ibm..." Strings are being removed as we approach our 1.0 release in fall.
- Yes we do intend to collaborate closely with the Platform and make services available in a general manner wherever possible.
- EFS integration has been improved, it is now possible to create projects on an remote EFS provided through RSE. This is still experimental though (not sure if it will make it into M2), your help here would be appreciated.
- Remote Search. I do not think that remote search actually duplicates current functionality, since the big plus of it is that all file accesses are remote with no actual data transfer. You cannot have this through EFS (every searched file is transferred to local).
- Datastore. Note that a remote datastore server can also be launched through an ssh channel for a single user only. So your point 1 "requires a service on the remote" is not true. The Dstore Daemon is just ONE of many launching options (though the most simple one). All you need is a 1.4 compatible JVM on the remote system. Datastore also supports SSL encoded transfer.
- As of now, ssh and sftp support has been added to the RSE.
- Refactorings are underway to better separate UI and non-UI parts of the RSE. Do you have specific needs for RCP?
We'd really like to collaborate more with the you, and the PTP project. RSE can, for instance, provide the shell channel through which remote build/debug can be started in a pluggable manner.
Regarding remote file support, I guess the big question is what setup you envision. Local replicated workspace (then you don't need remote search), Or a remote workspace (then RSE Filesupport would probably make most sense for you).
In any case, RSE shell / command support would make sense for you, I guess. With the ability to contribute RSE subsystems specific for remote parallel machines and their configurations in the future, share those in a team, visualize their status etc.
--- Martin Oberhuber, Target Management Project / RSE