Hello Folks, As I proposed in the last e-mail, I'm starting this thread so we can discuss further on restructuring our modules and puting everything inside the same namespace.
I liked João sugestion of creating a umit.common module for things that are used both by Umit and other projects. That looks better than keeping these things indefinitely inside umit.core, and in the future it may prove to be worth a change. First thing to decide is the namespace: would we use only umit or umitproject to avoid that confusion that we had before? I'll consider for my proposal that we're taking umit rather than umitproject as it is smaller, but it doesn't mean that it will be umit and that we can't change it yet. umit -> This is the base module name for the namespace. Don't forget to put a __init__.py inside it, otherwise your imports won't work. umit.higwidgets -> We'll be moving higwidgets to this namespace as well, for the same reason we'll be conducting that for the other libraries like UMPA and Zion. umit.db -> Currently this module is inside umit.db in the trunk. It won't be moved into umit.scan.db because it may be used by other projects. umit.plugin -> The current plugin module should be moved out of pm and umit, and be used by both through a unique namespace. Is that ok, Francesco? umit.plugin.geoip umit.plugin.schemas umit.plugin.traceroute umit.scan -> The scan refers to our scanning interface, which is Umit. umit.scan.core -> Our current umit.core module umit.scan.core.radialnet -> Our current umit.core.radialnet module umit.scan.core.qs -> The Quick Scan core module umit.scan.core.bt -> The Bluetooth Scanner core module umit.scan.core.preferences -> The main Preferences Window module umit.scan.core.preferences.actions umit.scan.core.preferences.conf -> The conf module for Preferences Window. Perhaps this should be merged into Umit's conf modules, our something similar? Not sure if we need this here. What do you guys think about it? umit.scan.gui -> Our current umit.gui module umit.scan.gui.bt -> The Bluetooth Scanner gui module umit.scan.gui.zion -> The Zion gui module umit.scan.gui.radialnet -> The current umit.gui.radialnet module umit.scan.gui.qs -> The Quick Scan gui module umit.scan.gui.ieditor -> The current umit.interfaceeditor module, but renamed to ieditor for short and moved into umit.scan.gui instead of feature the root umit.scan. umit.scan.gui.nse_facilitator -> The current umitNSEFacilitator module, moved into our main gui module. umit.scan.gui.preferences -> The Preferences Window gui modules moved into our main gui module. umit.scan.gui.inventory -> The Network Inventory, moved into our main gui module. umit.scan.merger -> The current umit.merger umit.scan.export -> The current umitExport module from Preferences Window branch umit.scan.web -> The web interface for our scanner umit.scan.web.control -> The control layer of the web interface scanner umit.scan.web.view -> The view layer of the web interface scanner umit.common -> Here we should put the common parts, like I18N, config files manipulation, Nmap XML files manipulation, etc. Another thread should be open to discuss on this later. umit.zion -> The backend for João's project. umit.zion.core umit.zion.db umit.zion.out umit.zion.scan umit.zion.sp umit.umpa -> The UMPA library. Perhaps the one that will need less modifications. umit.umpa.extensions umit.umpa.protocols umit.umpa.utils umit.pm -> The Packet Manipulation. We need to adapt the naming convention and put it inside our new namespace. Francesco, what do you think about the following? We need to keep in mind that bt_sniffer will feature the Packet Manipulator interface, therefore we need to foresee this project here also. Could you also add the modules necessary for your project this year? umit.pm.backend umit.pm.core umit.pm.core.bt_sniffer umit.pm.gui umit.pm.gui.bt_sniffer umit.pm.manager umit.pm.moo Aside this design, we need to decide on how to workaround situations of conflict, where a person is trying to use diferent versions for each of these modules. Eg. Installed last version of Umit that uses the last version of umit.common and user already have installed an older version of Packet Manipulator that uses an older version of umit.common already installed. The restructuring will be held gradually. The major priority is for those projects to be released soon like UMPA and Umit. UMPA is the easiest one, and it should go first as the current design for UMPA shouldn't change too much if there is any modification needed after all. The goal is to have UMPA restructured ASAP so other projects relying on it can start restructuring also. In the meantime that UMPA is being migrated, we finish this design and we start migrating the rest of the projects, starting by Umit and extending to other projects through Packet Manipulator. Let the design discussion begin! Kind Regards, -- Adriano Monteiro Marques http://adriano-marques.blogspot.com http://www.umitproject.org http://www.pythonbenelux.org "Don't stay in bed, unless you can make money in bed." - George Burns ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
