[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] CDT Launch integration
|
Hello again Tianchao,
to somewhat summarize what I've written earlier -
* I think you are wrong regarding remote search. It's a unique
RSE service that you cannot have through EFS. Unless the
EFS would be extended to provide an (optional) "remote search"
method...
[Also note that Eclipse Search can only search workspace
resources and you don't necessarily want to expose all remote
file systems to your workspace].
* We are considering EFS very earnestly. But note that the RSE
Remote Systems view is not just a re-implementation of the
Resource Navigator, since the RSE view can show not only
files but arbitrary remote subsystems / objects. We do keep
an eye on the Common Navigator though.
* Another particular power of RSE is in the combination of
Remote Files - Remote Shell - Remote Search which are
totally interoperable.
The real benefit of RSE is that it gathers lots of totally
heterogeneous systems and subsystems under a single
consistent view.
Cheers,
Martin
--
Martin Oberhuber - WindRiver, Austria
+43(662)457915-85
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Tianchao Li
> Sent: Tuesday, April 18, 2006 8:39 PM
> To: Target Management developer discussions
> Subject: RE: [dsdp-tm-dev] CDT Launch integration
>
> The distinction between implementing a file service in RSE
> and export it
> as a file system through the wrapper and directly extending the
> filesystem extension point is something to me not the suitability of
> bandwidth. RSE was initially designed and developed without the
> knowledge of underlying filesystem support, and the wrapper is only
> something that was found necessary to somehow provide
> interoperability.
> In fact, I sees that the RSE file subsystem is
> parallel/duplicate effort
> of the file system at the lower level. To be brank, the RSE need a
> complete redesign to rebase itself (especially the file service and
> search service) on the core.filesystem rather than the
> current secondary
> solution with patches.
>
> Regards,
> Tianchao
>
>
>
> On Tue, 2006-04-18 at 19:34 +0200, Oberhuber, Martin wrote:
> > Hi Greg,
> >
> > Dave D. may want to correct me, but as far as I know,
> >
> > 1. RSE already has a service plugin for org.eclipse.filesystem --
> > so when an external filesystem is contributed via the Platform's
> > extension point it will automatically show up as an RSE service,
> > and
> >
> > 2. It should be easy to take any RSE filesystem service and export
> > it as an org.eclipse.filesystem.
> >
> > So what you want depends on *how* you want your remote filesystem
> > integrated. RSE services see to be better geared towards connections
> > with lower bandwidth. Org.eclipse.filesystem seems to be
> better geared
> > towards total Platform Integration, at the cost of suboptimal data
> > transfer requirements.
> >
> > Cheers,
> > Martin
> > --
> > Martin Oberhuber - WindRiver, Austria
> > +43(662)457915-85
> >
> >
> > > -----Original Message-----
> > > From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> > > [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Greg Watson
> > > Sent: Tuesday, April 18, 2006 6:43 PM
> > > To: Target Management developer discussions
> > > Cc: Parallel Tools Platform general developers
> > > Subject: Re: [dsdp-tm-dev] CDT Launch integration
> > >
> > > Martin, Ewa,
> > >
> > > It seems like using the jcraft jsch is the preferable way
> to go for
> > > ssh support. The ability to execute arbitrary commands on
> a remote
> > > machine is exactly what we're after, so we'll keep an eye on the
> > > repository for your code.
> > >
> > > From our examination of RSE it looks like filesystem
> support is an
> > > either/or option, with RSE providing less functionality than
> > > the core
> > > filesystem support (correct me if I'm wrong here). Since our
> > > requirements are for the filesystem to be as transparent as
> > > possible,
> > > we're planning to focus on providing a remote filesystem
> using the
> > > core eclipse filesystem support. Hopefully there will be
> a way to
> > > utilize this from RSE in the future.
> > >
> > > Cheers,
> > >
> > > Greg
> > >
> > >
> > > On Apr 18, 2006, at 10:21 AM, Ewa Matejska wrote:
> > >
> > > > Hi,
> > > >
> > > > My plan was to write an RSE SSH Shell Service, time
> > > permitting, to use
> > > > with the CDT integration plugin instead of directly
> invoking ssh.
> > > > However, since it sounds like you've gotten the jcraft
> jsch plugin
> > > > integrated into RSE, I'll wait for that work to be
> > > submitted and I'll
> > > > default invoking ssh directly for now.
> > > >
> > > > Thanks,
> > > > Ewa.
> > > >
> > > > -----Original Message-----
> > > > From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> > > > [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Oberhuber,
> > > > Martin
> > > > Sent: Tuesday, April 18, 2006 2:05 AM
> > > > To: Target Management developer discussions
> > > > Subject: RE: [dsdp-tm-dev] CDT Launch integration
> > > >
> > > > Hi Greg,
> > > >
> > > > I believe that Ewa is using an external ssh program as channel.
> > > >
> > > > I have written an initial RSE integration for the
> internal jcraft
> > > > jsch plugin that comes with Eclipse team support. My integration
> > > > currently provides an RSE command view through the jsch channel.
> > > > I'm going to post my contribution as a bugzilla entry, to be
> > > > added to the RSE CVS Repository.
> > > >
> > > > The RSE's command channel can then be used to execute arbitrary
> > > > (also user-defined) commands on the remote side.
> > > >
> > > > An additional ssh service for sftp (integrated with RSE files
> > > > support) will be very simple to do.
> > > >
> > > > Plain scp is harder since there is no standard for the shell
> > > > commands to execute for directory listings, so I'm not planning
> > > > this now.
> > > >
> > > > Cheers,
> > > > Martin
> > > > --
> > > > Martin Oberhuber - WindRiver, Austria
> > > > +43(662)457915-85
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> > > >> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Greg Watson
> > > >> Sent: Monday, April 17, 2006 8:44 PM
> > > >> To: Target Management developer discussions
> > > >> Cc: Tianchao Li
> > > >> Subject: Re: [dsdp-tm-dev] CDT Launch integration
> > > >>
> > > >> Ewa,
> > > >>
> > > >> Are you checking your code into CVS anywhere? We're
> > > looking at using
> > > >> SSH for remote build/command execution and I'd prefer
> not to re-
> > > >> implement anything you've already done.
> > > >>
> > > >> Regards,
> > > >>
> > > >> Greg
> > > >>
> > > >> On Apr 17, 2006, at 11:23 AM, Ewa Matejska wrote:
> > > >>
> > > >>> Hi Mikhail,
> > > >>>
> > > >>> Yes...I've been working on the CDT/RSE Integration.
> I'm focusing
> > > >>> on using gdbserver with ssh. I will be posting a
> more thorough
> > > >>> description of my status within the next couple days
> with screen
> > > >>> shots. The integration introduces an experimental
> "C/C++ Remote
> > > >>> Application" launch configuration.
> > > >>>
> > > >>> Thanks,
> > > >>> Ewa.
> > > >>>
> > > >>> From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-
> > > >>> bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> > > >>> Sent: Monday, April 17, 2006 10:12 AM
> > > >>> To: Target Management developer discussions
> > > >>> Subject: [dsdp-tm-dev] CDT Launch integration
> > > >>>
> > > >>> Hi Martin,
> > > >>>
> > > >>> Is there any progress on this?
> > > >>> I am currently considering to add an experimental
> remote launcher
> > > >>> to the CDT. The RSE and gdbserver seem like a natural
> choice for
> > > >>> the reference implementation. I haven't tried the RSE
> yet, but we
> > > >>> can combine our efforts and come up with a better solution.
> > > >>>
> > > >>> Thanks,
> > > >>> Mikhail Khodjaiants
> > > >>> _______________________________________________
> > > >>> dsdp-tm-dev mailing list
> > > >>> dsdp-tm-dev@xxxxxxxxxxx
> > > >>> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> > > >>
> > > >> _______________________________________________
> > > >> dsdp-tm-dev mailing list
> > > >> dsdp-tm-dev@xxxxxxxxxxx
> > > >> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> > > >>
> > > > _______________________________________________
> > > > dsdp-tm-dev mailing list
> > > > dsdp-tm-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> > > > _______________________________________________
> > > > dsdp-tm-dev mailing list
> > > > dsdp-tm-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> > >
> > > _______________________________________________
> > > dsdp-tm-dev mailing list
> > > dsdp-tm-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> > >
> > _______________________________________________
> > dsdp-tm-dev mailing list
> > dsdp-tm-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> >
>
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
