Re: [aperi-dev] Aperi R4 planning

[Khan M Tasinga <kmtasing@xxxxxxxxxx>]

That's a pretty good list of potential
work-items. For the sake of discussion, I've listed some additional ones
that come to mind. It might be possible to start doing some of the work
identified below during the 0.3 timeframe.

- Move away from MS Visual C++ 6.0 for
native Windows compilation. Off top, a couple of potential alternatives
come to mind. First, depending upon things like legal constraints associated
with its use, we might be able to move to Visual C++ 2005 Express Edition,
which Microsoft makes available for free (http://msdn.microsoft.com/vstudio/express/visualc/).
Second, we can explore using GCC through Cygwin.

- Use fragments for native libraries.
We need to work around the issue described in the following bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=139064.

- Move batch reporting from the agent
to the server. Batch reporting, as it is currently implemented, requires
deployment of the entire legacy GUI to our agent. Moving batch reporting
to our server will reduce both the in-memory and filesystem footprint of
our agent.

- Data Server and Device Server consolidation.
Currently, the Data Server and Device Server run in separate OSGi containers.
In some respects, that fact is actually a good thing. However, it might
be nice to make it possible to run them within the same OSGi container.

- Host-based agent separation. Currently,
we package our Data Agent and Fabric Agent in a single OSGi container.
Would it make sense to give people the ability to run them in separate
containers? I don't think doing so would require making any code changes.
This would probably just be some packaging work.

- Automated test suite. I think putting
something in place would contribute greatly to the overall stability of
our code.

- Move away from Apache SOAP. Given
that Apache SOAP satisfies our existing requirements, moving to something
new probably isn't all that necessary. However, it might be interesting
to explore what advantages we might reap by moving to something like Axis
(http://ws.apache.org/axis/) or Axis2 (http://ws.apache.org/axis2/). It
might be possible to build on top of some of the work being done by the
Corona project (http://www.eclipse.org/corona/).

- Operating system support. While our
legacy GUI is capable of running on any machine with a JVM, such is not
the case for our agents and servers. Currently, our agents and servers
run on Windows and Linux. There might be some interest in seeing them run
on other OSes (e.g., AIX, Solaris, etc.).

- Database support. Aperi can run against
Apache Derby and DB2. There might be some interest in additional database
support (e.g., Oracle, MySQL, PostgreSQL, etc.).

- Additional enhancements to extensibility
and componentization, throughout Aperi. For example, on the Data Server,
while it's possible to add things like resource attributes and alert conditions,
doing so in a way that allows different vendors to share the same instance
of Aperi is cumbersome. As such, there's probably room for improvement.

Regards,
Khan Tasinga
IBM Tivoli Software Engineer
Dept: DQUA / Bldg: 050 / Office: A152
5600 Cottle Road, San Jose, CA 95123 
Phone: (408) 284-5142 | T/L: 8-953-5142
Email: kmtasing@xxxxxxxxxx

Ted Slupesky/Portland/IBM@IBMUS
Sent by: aperi-dev-bounces@xxxxxxxxxxx

12/05/2006 01:56 PM

Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx>

To	aperi-dev@xxxxxxxxxxx
cc
Subject	[aperi-dev] Aperi R4 planning

Hello, 

I'd like to start the work for planning for Aperi's R4 release. I will
list here the candidate work items from our roadmap and also the 'future'
work items. For each candidate, I'd like to identify an owner in this coming
Monday's development meeting. I'd like the owner to be responsible for
learning enough about the candidate work item to be able to propose various
technical solutions to achieve it... which will ultimately turn into sizings
and project plan. But for now, technical investigation is what is called
for. 

Now that our code is available in eclipse.org, this is the first time we
can engage in a release planning process completely in the open -- and
it's a great opportunity for interested developers who haven't been actively
participating to start doing so. 

The R4 items from our roadmap are:

• SMI-S Fabric & Switch profiles (*)
• SMI-S NAS profile
• Unified Storage support (FC, NAS composite view)
• Complete Eclipse RCP GUI

Items we identified as future work items -- with sufficient interest we
could move some into R4:

• IP storage support
• SMI-S Virtual Fabric subprofile
• BSP profile
• Performance statistics for unified storage via SMI-S
• Host profile
• CLI
• Remote install & upgrade of host agents
• Role-based access control – finer-grained role definition and application to profiles
• Increased support for storage virtualization (beyond inband virtualizer)
• Application awareness

Of course we are free to re-evaluate these lists. If there is sufficient
interest in the community, the roadmap can certainly be adjusted and items
added (or removed). In fact I would like to propose some additional candidates:

• Port binding
• Improved data model for reporting

Feel free to respond with your feedback regarding this list and any changes
you'd like to see (and to volunteer for an item, too!). We'll discuss this
further in Monday's call. 

Note: SMI-S Fabric & Switch profile support have a * next to them because
this is an area where IBM has code to contribute (I'd be happy to discuss
alternative implementations however). 


--
Ted Slupesky | Eclipse Aperi Project Lead | IBM: 349-5413 | External: (503)
820-3853
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev