[
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?)
|
PS:
What if the ILaunchActionType were responsible for
deserializing ILaunchActions? - It could act like
a factory for ILaunchActions... this would be in
line with a concept used elsewhere at Eclipse...
Cheers,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: Oberhuber, Martin
> Sent: Wednesday, January 17, 2007 9:26 PM
> To: 'Robert Norton'
> Cc: dsdp-tm-dev@xxxxxxxxxxx
> Subject: 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
> > >
> > >
> >
> >
