[Kimchi-devel] [RFC] Split Kimchi into Base Framework and Virtualization layers

[Lucio Correia]

Hi,

Due to the nature of this change, we may need a special plan to adopt 
it. Let me know how can we handle it for 1.5 release.

It's a high sensitive code change, with several renames and challenging 
rebases. It would be nice to keep focus on the refactoring itself in a 
first phase, then add nice features on a second phase.

BTW, I've already moved swupdate.py, repositories.py, and screenshot.py 
as recommended by Royce. See below for netinfo.py.

Follows a design summary and the challenges I need your help to solve. I 
still have much to finish here, but I can provide a branch for you to 
look how it is as of now.


Design Summary:

Framework provides menu interface, installed plugins adds tabs to that 
menu. All tabs of all plugins are showed at the same time.

Scenarios for web-framework default access:
 > No plugin installed: a welcome page shows a message like "no plugin 
installed"
 > One plugin installed: redirect user to it (its first tab)
 > More than one plugin installed: redirect to first loaded plugin. We 
may create a mechanism to define the plugin order.



Challenges:

Main logo and About window:
- We may create a mechanism for the plugin to provide that. It may be a 
specific file name in the first phase, and an API for a second phase.

Peers functionality is on title bar - possible solutions:
- Make it a tab
- Provide a mechanism for plugins to insert such kind of thing there 
(best for a second phase).

netinfo.py is in use by ginger, possible solutions:
- keep it as a utility from web framework
- duplicate it in kimchi and ginger plugins


Thanks,
-- 
Lucio Correia
Software Engineer
IBM LTC Brazil