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

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: installed" 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