Skip to main content

[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?

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


Back to the top