| Re: [aperi-dev] Aperi UI Futures: a concrete strawman |
Hi, I would like to step back a little. Given the fact that storage
management is still painful today (deploying a SRM solution takes a whole
lot of time), should we not focus on the pain points? I would readily
admit that a GUI is an important part of the systems management experience,
however we need a strong justification with regards to the weaknesses of
the current GUI to warrant developing another one.
I guess this is a call for prioritization, and may need access to storage
management surveys.
Regards,
Prasenjit Sarkar
Almaden Research
Dave
Wolfe/Portland/IB
M@IBMUS To
Sent by: aperi-dev@xxxxxxxxxxx
aperi-dev-bounces cc
@eclipse.org
Subject
[aperi-dev] Aperi UI Futures: a
02/06/2007 05:34 concrete strawman
PM
Please respond
to
Development
<aperi-dev@eclips
e.org>
As discussed in an earlier email we are trending towards a web based
solution for the Aperi UI.
This trend requires some new infrastructure be put into place to support
the new model.
Specifically we will need a portal server (open source, of course) and an
Ajax framework.
A portal server implies an application server and an application server has
to be hosted somewhere, and once you start talking about application
servers all kinds of annoying questions about deployment and security start
coming up.
One thing that is for sure is that this application server is for
presentation services only, so it should be considered as isolated from any
other application server in the back end (or should it?).
But, the way I envision it right now is with the application server
embedded in the data server internally accessing data server service APIs
via POBs.
I think this is probably a bit naive, and it makes our server picture more
convoluted, so I could use some help on why this won't work and what other
alternatives I have.
Asserting POBs here is saying I want to keep the footprint small so I don't
want to take on a framework (Springs, Struts, EJBs, etc). I think this is
OK given our Ajax leanings (the MVC pattern moves to browser?).
(Embedded image moved to file: pic29145.gif)
The portlets just provide containment for the Ajaxified controls that feed
on XML streams (not pictured).
In addition to serving portlets the application server can also serve BIRT
reports (also not pictured) which would move report generation from the
client (as it is today in the V0.3 RCP GUI) to the server.
The console framework depicted above is our rich client framework with a
browser window to present the web based content, but conceptually could be
any framework.
All portlets will have to be written and tested for portability for the day
when we move from the rich client framework to a fully browser based
console.
Dave Wolfe/Portland/IBM (dwolfe@xxxxxxxxxx) TL: 775-3376 Office:
503-578-3376 Personal: 503-329-3960
GUI Technical Lead, Aperi Open Source Storage Management
http://www.eclipse.org/aperi http://www.ibm.com.
If all of your problems look like nails you should invest in a good hammer
- Unknown_______________________________________________
list
https://dev.eclipse.org/mailman/listinfo/aperi-dev
Attachment:
pic29145.gif
Description: GIF image
