[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aperi-dev] launching individual, context-based functionality via URL instead of RPC plug-ins?
|
> Has anyone on the project thought
about a slightly different plug-in model for Aperi, along the following
lines? Say a vendor is planning to write an Element Manager...
Indeed we have. In fact there is an
item on the 'what next' list (http://wiki.eclipse.org/Release_Planning)
named 'Launch In Context (LIC)' which is exactly what you described.
Aperi already has the ability to launch
the URL of an Element Manager of a Storage Subsystem, Switch or Tape Drive
into a separate browser window or application, but not 'In Context'.
What does 'In Context' mean? Well, at
minimum it means do something more than just drop the user on the Welcome
page of a web based tool. Ideally we would like single sign on, automatic
navigation to the relevant screen in the element manager, and cross product
object identification so that the end result is the user lands on the right
screen to perform the desired function on the object they had selected
in the source GUI.
The vision is a user sits down at the
topology viewer or dashboard and navigates around in the GUI looking for
the source of a problem, or free space, or that switch connected to the
subsystem who's name I can never remember, what ever. Once they find the
object of their desire they right click (perhaps) and are offered a menu
of possible operations. Some of those operations are intra-GUI and use
Aperi capabilities while some of them are extra-GUI and will launch an
element manager of one kind or another. The external launcher will pass
parameters to the element manager for authentication, GUI navigation, and
object identification.
As you say its a looser integration,
at the GUI navigation level rather than the data collection level, but
at that it will offer a less restrictive method to integrate products.
Of course, there are
According to Tom's roadmap process we
can promote items from the "what's next maybe" list to the "what's
next for sure" list if their is sufficient interest...
Dave Wolfe/Portland/IBM
(dwolfe@xxxxxxxxxx)
TL: 775-3376 Office: 503-578-3376 Personal: 503-329-3960
UI Technical Lead, Aperi Open Source Storage Management
http://www.eclipse.org/aperi
"A good composer does not imitate; he
steals." - Igor Stravinsky
"Monesson, Jenny"
<Jenny.Monesson@xxxxxxx>
Sent by: aperi-dev-bounces@xxxxxxxxxxx
09/12/2007 01:08 PM
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx> |
|
To
| "Aperi Development" <aperi-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| [aperi-dev] launching individual,
context-based functionality via URL instead
of RPC plug-ins? |
|
Hi All,
Has anyone on the project thought about a
slightly different plug-in model for Aperi, along the following lines?
Say a vendor is planning to write an Element Manager that can be
served off of their device to a browser via an embedded web server. The
EM supports a number of functions that are vendor unique, (e.g., get device
statistics, run diagnostics, etc.) for which it might be nice to have Aperi
plug-ins. What if those functions were exposed as individual URLs
that could be launched in context from Aperi (versus having just a single
URL for the EM “main page”)? This provides a way to have a somewhat
“deeper” level of integration with Aperi without having to write the
vendor unique functions twice (once for the Element Manager browser-based
environment and once for the Aperi runtime environment). One drawback
is that it is not as seamless as the regular Aperi plug-in mechanism. Is
this feasible with Aperi? Would it work?
Thanks,
Jenny
Jenny Monesson, Ph.D.
Solutions Architecture
LSI - Engenio Storage Group, Austin TX
jenny.monesson@xxxxxxx
Voice: (512) 794-3723
Fax: (512) 794-3702
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev