[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-tm-dev] RE: Advanced Remote Launching (was: Is TM/RSE right for us?)
|
Hi Robert,
this looks awsome and is pretty much in line with what
I had in mind. Few comments only:
* with respect to serializing / deserializing itself,
I thought I'd not tie this to the ILaunchConfiguration
but allow the ILaunchActions to read from / write to
a plain String. Actions are free to use XML or whatever
in the String.
Using plain strings will allow us to nest ILaunchActions
in control structures etc. if we need to. and/or use
them independent of LaunchConfigurations (e.g. context
menu actions etc).
Also, the ID of the ILaunchActionType seems to be
synonymous to the prefix you propose so I'd consider
the prefix obsolete.
* [advanced, probably future]
Another idea for serializing / deserializing I had,
was to allow ILaunchActions to be configurable not only
through a UI but also as text similar to a shellscript,
e.g.
download -local /my/file -remote /target
Wondering if it were possible to leverage the framework
of some script interpreter like Jython or Jtcl -- need
to check the Dash / EclipseMonkey project for that
* ILaunchActionContext is a great idea. I guess that the
context will have more information, e.g. the current
connection to work on or even a current diretory for
commands.
Other items of the context could be similar to String
"variables" which can be expanded in other actions.
This would allow an action A to get some information on
the target, store it into a "variable" and have an action
B to act dependent on the result of that variable.
* ILaunchAction.perform() should have some way of returning
a status (success / error). This could be a return value,
or could be done by modifying the context it gets.
The sequencer shall be able to decide whether remaining
actions are executed or not in case of an error.
Looks like the trick of the next step will be to come
up with a simple first version that's not too ambitious
but extensible enough for future enhancements ;-)
Cheers,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: Robert Norton [mailto:rnorton@xxxxxxxxxxxx]
> Sent: Wednesday, January 17, 2007 12:57 PM
> To: Oberhuber, Martin
> Cc: dsdp-tm-dev@xxxxxxxxxxx
> Subject: RE: Advanced Remote Launching (was: Is TM/RSE right for us?)
>
> Hi Martin,
>
> Thanks for your response.
>
> > If you like this idea,
> > please get in touch with us on the dsdp-tm-dev@xxxxxxxxxxx
> > mailing list for further exchange of concrete design ideas.
>
> I do like the idea! Based on your description for a generic launch
> action framework I put together some class diagrams which I
> have posted
> on the wiki (they are linked at the bottom of this page:
> http://wiki.eclipse.org/index.php/DSDP/TM/Launching). Does this
> correspond roughly with what you had in mind?
>
> The most interesting bit is probably the method used to
> persist the tree
> of actions into the ILaunchConfiguration. I decided that each
> ILaunchAction implementation should know how to load / save
> itself using
> a given prefix before its configuration keys. This way it ought to be
> possible to flatten an arbitrary tree of ILaunchActions without any
> naming collisions.
>
> ILaunchActionTypes are contributed via an extension point and contain
> all the information necessary to instantiate the corresponding
> ILaunchAction using the GUI, including an
> ILaunchActionConfigurationPanel (second diagram).
>
> There is no RSE dependency except that certain ILaunchActions might be
> implemented using RSE functionality (e.g. a remote shell command
> action).
>
> Any thoughts and suggestions much appreciated.
>
> Robert
>
> > -----Original Message-----
> > From: Martin Oberhuber [mailto:martin.oberhuber@xxxxxxxxxxxxx]
> > Sent: 15 January 2007 16:21
> > To: Robert Norton; dsdp-tm-dev@xxxxxxxxxxx
> > Subject: Advanced Remote Launching (was: Is TM/RSE right for us?)
> >
> > Hi Robert,
> >
> > it's great to hear that you want to extend the TM / RSE
> > Launching mechanism, and also think about contributing back
> > your enhancements.
> >
> > As Torkild has already pointed out, adding Shell Operations
> > to a Launch by adding them to the LaunchDelegate "hardcoded"
> > should be fairly easy.
> > If you want to have your shell commands independent of the
> > protocol (ssh, telnet, dstore, or whatever contributed), you
> > might want to consider extending
> > org.eclipse.rse.subsystems.shell.core.model.SimpleCommandOperation .
> >
> > For some sample code that deals with running commands on the
> > remote side, see org.eclipse.rse.examples.tutorial/ShowJarContents
> > as well as the MontaVista ssh processes contribution, which
> > is currently available from Bugzilla at
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=159522
> >
> > With respect to making such shell (or download) actions as
> > part of a Launch generic, we already have a concept for this.
> > The idea is to have an additional tab in the Launch, where
> > you see a list of entries. Each entry is of type
> > ILaunchAction, where implementations of ILaunchAction can be
> > contributed through plugin.xml. Each ILaunchAction brings an
> > associated UI for configuring it.
> > Examples of ILaunchAction could be a
> > RunShellCommandLaunchAction, or a DownloadFileLaunchAction,
> > each of which could use RSE services in turn.
> > The LaunchActionSequencer, which runs one action after the
> > other can even be generic (independent of RSE), just like the
> > LaunchActionManager which would be responsible for persisting
> > the ILaunchAction data into ILaunchConfiguration instances.
> >
> > Unfortunately, this excellent idea isn't currently being
> > implemented due to lack of resources. If you like this idea,
> > please get in touch with us on the dsdp-tm-dev@xxxxxxxxxxx
> > mailing list for further exchange of concrete design ideas.
> > It would be great if you could work in this direction and
> > contribute some code. The online place for more details is at
> > http://wiki.eclipse.org/index.php/DSDP/TM/Launching
> >
> >
> > Thanks,
> > --
> > Martin Oberhuber
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> > Robert Norton wrote:
> > > Greetings All!
> > >
> > > I've been given the task of adapting Eclipse to the needs of our
> > > developers and have identified that one of our requirements is to
> > > simplify the process of configuring and launching a debug
> > session on
> > > an embedded target (or simulator). Since this is exactly
> > the sort of
> > > thing that TM/RSE is supposed to handle I thought I would
> > give a shout
> > > on this mailing list to see if anyone can offer any suggestions.
> > >
> > > The basic problem is that setting up a debugging
> > environment for us is
> > > much more complicated than the default CDT (+ Zylin
> patches) launch
> > > configuration allows. In particular it might involve
> > starting several
> > > different processes (each with specific options, sometimes
> > on a remote
> > > target) in the correct order and finally connecting a gdb process.
> > >
> > > From scanning the available documentation I get the
> > impression that
> > > TM and RSE provide a basic framework which could be used to
> > automate
> > > much of this, but I'm still unclear on exactly how it could be
> > > achieved. For example might it be possible to create a new debug
> > > configuration type tailored to each of our debugging
> scenarios and
> > > leveraging the RSE functionality? I'm keen to create as general a
> > > framework as possible for starting auxiliary process and
> > would love to
> > > contribute back any code I produce (subject to the
> > agreement of management / legal bods.).
> > >
> > > Does anyone have the slightest idea what I am talking
> about? If so,
> > > can you offer any comments or suggestions?
> > >
> > > Cheers,
> > >
> > > Robert Norton
> > > DSL Unit, Broadcom UK
> >
> >
>
>
