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.
>
>
> 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?
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?
>
> 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
>
>
> 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 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
