[
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?)
|
> Was there a particular reason why you didn't put the tm-dev
> mailing list on CC with your reply?
Just forgot!
> I very much hope that your legal team's ok with a contribution.
Me too!
Robert
> -----Original Message-----
> From: Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
> Sent: 02 February 2007 10:19
> To: Robert Norton
> Subject: RE: Advanced Remote Launching (was: Is TM/RSE right for us?)
>
> Cool!
>
> Was there a particular reason why you didn't put the tm-dev
> mailing list on CC with your reply?
>
> I very much hope that your legal team's ok with a contribution.
>
> 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 31, 2007 6:32 PM
> > To: Oberhuber, Martin
> > Subject: RE: Advanced Remote Launching (was: Is TM/RSE
> right for us?)
> >
> > Hi Martin,
> >
> > > I apologize for taking so long before I get back to you - been on
> > > business trip lately.
> >
> > No problem.
> >
> > > Did you have any chance to further develop that idea?
> > > What do you think should be the next steps?
> >
> > I've been working away quietly on this and have come up with quite a
> > capable framework. It's close to being able to do everything I need
it
> > to do at which point I will most likely have to move on to some
other
> > project (I've spent quite a lot of time on this already). I'll also
get
> > on to management to check the legal position so that I can finally
> > show you some code!
> >
> > Property types:
> > I went with the list of types I gave you and added an abstract
> > isExpressibleAsString method to the Property class. Sub-classes
(e.g.
> > StringProperty, IntegerProperty...) can override this and provide
> > setFromString and getAsString methods allowing persistence to be
> > independent of property type for these types. Property types which
are
> > not expressible as a string (the only example at current is
> > lists of launch actions) require specialised code in the
serializers.
> >
> > All in all I'd say there are certain aspects of the framework which
> > I'd like to see cleaned up a bit before releasing it as an API, but
> > the concept is definitely a useful one and with a bit of work has
some
> > real potential.
> >
> > Cheers,
> >
> > Robert
> >
> > > -----Original Message-----
> > > From: Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
> > > Sent: 31 January 2007 17:12
> > > To: Robert Norton
> > > Cc: Target Management developer discussions
> > > Subject: FW: Advanced Remote Launching (was: Is TM/RSE
> > right for us?)
> > >
> > > Hi Robert,
> > >
> > > I apologize for taking so long before I get back to you - been on
> > > business trip lately.
> > >
> > > I've been pondering this idea more and I really like it!
> > > Storing the launch action's properties together with
> > > meta-information reminds me of component models like JavaBeans or
> > > .NET and should allow for lots of cool things without being too
> > > complex. The great thing about this is that there can be multiple
> > > means for acquiring the needed data (UI editor, script,
> > > plugin.xml...). Following such a component model, there could be
> > > some Properties which "read" data
> > > (input) while others could "write" data (output) by
> writing into a
> > > reference like a variable.
> > >
> > > With respect to the types you listed, I think I'd still
> like to keep
> > > the "plain data type" like String/Integer/Boolean/List
> separate from
> > > the meta-information that associates a meaning or UI
> restriction on
> > > the plain data (Enumeration; localFile; remoteFile;
> > > otherLaunchAction; otherLaunchConfiguration etc). Some
> layers like
> > > the persistency mechanism don't need to know about the meaning of
> > > some data, they just need the data type (String).
> > > The PDE extension point editor (.exsd) stores its meta-info also
> > > separate from the data type.
> > >
> > > I like your idea of separating property name from property label.
> > >
> > > With respect to existing code, I'm sure that something must exist
> > > already since PDE is in quite a similar situation with the
> > > plugin.xml / extension editor forms (driven by the .exsd files).
> > > Unfortunately I've not had time to search for concrete code. EMF
> > > Editors also do generic forms, though I'm not sure we'd
> want an EMF
> > > dependency for this.
> > >
> > > Did you have any chance to further develop that idea?
> > > What do you think should be the next steps?
> > >
> > > Thanks again for this fruitful discussion.
> > >
> > > Cheers,
> > > --
> > > Martin Oberhuber
> > > Wind River Systems, Inc.
> > > Target Management Project Lead, DSDP PMC Member
> > > http://www.eclipse.org/dsdp/tm
> > >
> > >
> > >
> >
> >
>
>
