Thanks, Dave.
And would we be able to launch these as
context-sensitive URLs or would they need to be based on RCP?
Thanks,
Jenny
From: aperi-dev-bounces@xxxxxxxxxxx
[mailto:aperi-dev-bounces@xxxxxxxxxxx] On
Behalf Of Dave Wolfe
Sent: Thursday, September 13, 2007
9:53 AM
To: Aperi
Development
Cc: Aperi
Development; aperi-dev-bounces@xxxxxxxxxxx
Subject: 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