> Firstly I want to say that I'm agree with umit name for namespace. So, we're 2 by now.
> I would like that we can design a nice structure, so we need to invest time > in improving and studying it, and see the possibilities considering the pros > and cons because it will not to change during a long long time, I hope. Indeed. That's the purpose of this thread. But we won't leave this threat open forever. If no one else comes with a better design idea, we'll have to move on with what we have. >> 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? > > I can treat it, in the right time. It can guarantee that is not interfering > with the design, so we need do apply "divide and conquer" strategic. Each > step on the right time. Sure. I listed the whole thing, but we'll certainly be converting gradually. That will come when preferences window will get integrated into Umit. >> 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. > > Well, it have some costs, so it is not reasonable to work on this in version > 1.0. > My proposal is just move the name space to scan, that is a easy task, and > doesn't separate the project integrated in core/gui. I think I didn't understand the whole idea. Do you mean to simply move current modules into umit.scan, and then latter do the further movings? If it is, I think that the costs of doing that is the same as dois the whole thing once, then I would rather do it once to avoid breaking plugins and other code that people will develop here. > It could be improved on 1.1 and gradually in next versions. > Is it looks reasonable? I would prefer to do that sooner rather than later, due to the fact that we may break plugins and harden the work for our socers by changing that during soc. There are some refactoring tools that could help us on that. >> 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 conflicts with old versions should be *avoid*. So I was thinking about > it, at least I didn't see any problems, not yet. The conflicts may happen. We need some sort of intelligent installer that check the version installed, and if there is an old version, perhaps we could install the lib somewhere else and put it first on app's path, or another similar solution. > I don't have more comments. That's all. I'll wait for the final answer about > namespace and the design, then I could do restructuring of namespace on Umit > Scanning ;) The way it goes this far, we'll end up with something similar to the current proposal and umit as namespace. That would be great if you could help us on Umit. Let me know if you need any help, and try to gather some of your stundets to give you a hand if necessary also. 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
