[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-tm-dev] RSE as a Hardware Configurator
|
Hi,
Thanks for your reply!
I filed the following bug report, which contain both design document and
plugins implementations:
Apply to Project:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247876
HostCombo widget:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247878
The Automatic Project Cache:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247879
Regarding your questions, please read below:
Oberhuber, Martin wrote:
Hello Serge,
this sounds interesting!
We've been interested in the Remove System Explorer for some time and
^^^ Freud'ian mis-typing? :-)
Yes indeed ;)
We're not yet doing communication with the target through RSE, we're
only using it as a central repository for target settings.
This makes sense, and is one of the reasons why we, too, use RSE.
For future efforts in that direction, are you aware of
http://wiki.eclipse.org/E4/Connection_Frameworks ?
I am not aware of this effort, but I'll certainly take a look.
The first thing we did is a "HostCombo" widget that is a bit more
Hmm, at the very first sight, I'm not sure if your enhancements
are generic enough to make it into the core RSE framework. Did
you have to patch core RSE code in order to make these enhancements,
or have you been able to put these into separate plugins?
Taking the HostCombo: what is the semantics of a selection? A host
or a subsystem? What's the meaning of selecting either the one or
the other? I'd like to have more context of how you're using this.
At the moment, the implementation is in a separate plugin. The widget
selection can be either a Host or a Subsystem, or any of the two.
You'll find the exact API in the bug report, there's a detailed document
attached to it.
We tried to make it as generic as possible, and I believe it is fully
reusable by anyone else (minus the package change)
The second feature is what we call "ApplyToProject" (see the
Apparently this can be applied only to Launch Configs that have
a reference to an RSE connection. So some generic markup for
such launches is needed, in other words: an (abstract?)
base class for Launch Configurations... which might actually
be a good idea.
The feature has an extension point that allows components (such as
Launch Configuration) to expose "Applicators" so that a host or
subsystem can be applied to them.
In our case, we have also Software Analysis settings that will reference
the RSE, not only Launch Configuration, hence this Applicator
abstraction that we're using.
In the bug report there's a detailed description of the Applicator
interface.
The third feature we've added is an Automatic RSE host project cache
By "project referring to a host", do you mean "Launch Configuration
associated with the project referring to a host" ? I'm wondering
how you're moving your hidden project around. That seems to be
just another way of persisting connection data... basically, a
"lazy persistence provider" which remains idle and unpersists its
information only when needed.
This seems a good generic idea, but I wouldn't want to tie the
mechanism of persistence to "hidden project" only, we're actually
moving away from that, I'd be more in favor of adding the concept
of "laziness" to the generic persistence provider extension point.
Then others, who are persisting their hosts by other means, can
also do that (an you could keep the "hidden project" in your own
persistence provider extension).
We are not storing the cached Host in a hidden project, but in a hidden
project file. Each project that has component referencing a RSE host
has an "rseHostSettingsCache.xml" created to store the settings.
When I say it's invisible, it's only invisible because of the View
filters, the user can still see it as a normal file to move it around
with other project files in a source control repository.
You'll find more information in the design document in the bug report as
well.
Thanks for taking the time to look at it!
Serge Beauchamp
Freescale Semiconductor
