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.
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
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.
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
IBM LTC Brazil