[
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,
> -----Original Message-----
> From: Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
> Sent: 17 January 2007 20:26
> 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.
This sounds reasonable. The only concern I have is that if actions can
be nested as you suggest (and this seems logical) then the xml
configuration for one item might well contain the xml configuration for
another and it is very easy to get considerable blow up of escaped
characters (<element> => <element> => &lt;element&gt; =>
&amp;lt;element&amp;gt; ...). Perhaps this isn't much of a
problem if nesting is limited but it's worth thinking about. I only
mention it because I have been bitten before by a similar problem.
> 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.
I didn't make clear the purpose of the prefix here. In fact it achieves
the same flexibility as using plain strings as follows:
The namespace of configuration keys is divided up hierarchically. Each
instance of ILaunchAction is free to use the namespace below its prefix
in any way it sees fit. A composite ILaunchAction (e.g. a sequence of
actions) might divide up the namespace between each of its children by
numbering them then instructing them to store their configuration using
a prefix composed of the prefix passed in plus the number assigned. This
is different from simply using the ID of the LaunchActionType since
there might be more than one instance of a particular action type in a
sequence.
> * [advanced, probably future]
> Another idea for serializing / desterilizing 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
This would certainly be an interesting feature. As an intermediate
solution we could implement a 'jython' action which allows the user to
enter some arbitrary jython script which is persisted in the normal way,
though this doesn't really give the same flexibility.
> 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...
Yes I had considered this also. The reason I put the method in
ILaunchAction instead is that I intended for ILaunchActionType to be
simply a data object for passing around the action type contributions
from plugin.xml. This would be handled by a LaunchActionTypeManager
class (not shown in diagrams) which provides the ILaunchActionType
implementation. Thus the only action specific code for a particular
action type is the ILaunchAction implementation, whose class is
specified in plugin.xml. Please let me know if this makes sense.
--
On serialization methods in general, I think one important aspect of the
serialization mechanism will be the ability to include the result in
plugin.xml files. I would like a mechanism for providing pre-configured
sets of launch actions for common debug scenarios. These should be
contributed via a plugin and appear in the UI as a launch configuration
type (or perhaps some other mechanism). In order to achieve this we need
a serialization format which is concise and readable. Being independent
of the LaunchConfiguration mechanism would be useful too, though not
necessarily critical (e.g. we could get around this by writing our own
ILaunchConfiguration implementation which emits xml suitable for
inclusion in plugin.xml).
Given this requirement I'm still uncertain what the best mechanism will
be. I think something more structured than plain strings would be
desirable since otherwise we will end up with a proliferation of ad-hoc
methods for marshalling data into string format and I doubt the result
will be very readable. Also it's something which is common to all action
types so we really should provide some more comprehensive framework
rather than encouraging code-duplication. I'm open to ideas on this one
so please feel free to disagree.
> * 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.
That's certainly the idea: separating out the context into a separate
class gives us the flexibility to add extra things as we go on without
too much pain (much like the ServletContext idea from Java servlets).
> 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.
I very much like this idea -- it would make it possible to implement a
Turing complete set of action types! It would also be useful for
adapting pre-configured action sets e.g. by setting a global variable
which is then picked up by individual actions. It would be nice if
variables could be referenced anywhere a text based configuration
parameter is required.
> * 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.
Yes I hadn't really thought about this. Would a throws declaration on
the method suffice? The advantage of this over a return value is that
the compiler ensures that it is checked.
> 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 ;-)
Agreed. Actually I made a start on the implementation yesterday and it's
going quite well. I think we need to resolve the serialization issue
before I take it any further, however. Also I need to update the UML
diagrams with some minor changes I made.
I haven't had any response from management yet on my legal status. I'll
get back to you (hopefully with some code) as soon as I know.
Many thanks,
Robert
> 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
> > >
> > >
> >
> >
>
>
