[
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?
|
They would be GUI technology independent,
and context-sensitive URIs.
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/13/2007 12:59 PM
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx> |
|
To
| "Aperi Development" <aperi-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [aperi-dev] launching individual,
context-based functionality via URL
instead of RPC plug-ins? |
|
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_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev