Hi Folks! Firstly, sorry fo the delay of answering to this thread. I was a little busy this days. But let's see this:
On Tue, May 5, 2009 at 6:18 PM, Luis A. Bastiao Silva <[email protected]> wrote: > Hello, > > Firstly I want to say that I'm agree with umit name for namespace. > > 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. > > On Tue, May 5, 2009 at 11:30 AM, Adriano Marques <[email protected]> > wrote: >> >> 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. I choose the 'umit' namespace. >> >> >> 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? Ok, I think I disagree about this structure map. I would choose a simpler package structure. For example, in my case, I use the umitWeb (soon it will be umit.web) package. The core classes are already in the umit.web package, and I won't need an additional umit.web.core, for example. Ok, this is my 2 cents: I vote for a structure that is like that one we already have: umit.core => core libs. I think this package is being used (and will be used) for the most part of projects. If new functionalities can be integrated, then it should be added to the umit.core. But I think *here* we should put a 'scan' package, regarding to the network scanner, the nmap interface. Then, umit.core could adopt this layout: umit.core umit.core.scan umit.core.bt umit.core.qs umit.core.future_core_projects This way, the umit.core package would be a container to our 'core technologies'. Following the same rule, we could design the gui module: umit.gui umit.gui.scan umit.gui.preferences umit.gui.networkinventory umit.gui.bt umit.gui.qs Then, the web packet (I think it doesn't fit in the "gui" package): umit.web umit.web.views The database module: umit.db And so on. Forgive me if I forgot some packages from umit.gui, I'm not so familiar with that. So, the independent products, Like Zion, UMPA and Packet Manipulator would reside directly inside the umit package: umit.umpa umit.pm umit.zion But I didn't get a concisious way about how put the GUI part of umit.pm and umit.zion. We could brainstorm here about this model and try to define some things. > > 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. > >> >> 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. > > It could be improved on 1.1 and gradually in next versions. > Is it looks reasonable? I agree, but I think we should talk more about the structure. > > >> >> 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. > > Ok. Indeed. > >> >> 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 Maybe it should follow this way, indeed. (I'm talking about my indecision above, about where to put the gui packages, etc.) >> >> >> 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. > I think we should work on setuptools-based installers. It should be the best way to avoid this type of conflict. And another important thing: Maybe we should adopt a way to idenfity the umit's version inside each module (Like a $Version$ in the headers, or something like this). This way, we could detect different versions, and give a clear error message for the user. >> >> 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 > > 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 ;) > > Best Regards, > -- > Luís A. Bastião Silva > > > ------------------------------------------------------------------------------ > 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 > > Ok, that was my 2 cents =) Cheers! -- Rodolfo Carvalho Web Developer [email protected] ------------------------------------------------------------------------------ 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
