Hello Luis,
Thanks for your input! I'm commenting inline...
Em 27 Jul 2009, às 13:23, Luis A. Bastiao Silva escreveu:
Hello Adriano,
On Mon, Jul 27, 2009 at 10:31 AM, Adriano Monteiro Marques <[email protected]
> wrote:
Hello folks,
I'm creating this thread to discuss what do you guys think should
feature umit.common instead of somewhere else, due to the fact that it
is something that is (or can be used) by other softwares here at Umit
Project that are currently being duplicated. I'm writting a
documentation for all our namespace, and this is the time to give this
module a serious thought.
I think it should feature code related to
subjects like: I18N, L10N, Logging, Configuration file manipulation,
Regular expressions, etc.
Ok!
It was the deal.
This changes sounds very good. I just have some remarks:
So, files like the following:
umit.core.Paths
umit.core.BasePaths
Please don't move it to common because this module references too
many things about Umit Network Scanner. This files is specific of
the project.
Create a module called EnvironmentPaths sounds reasonable and avoid
some problems below.
Indeed, you're right, but please note that most files here are in the
same condition as Paths as they will probably need some sort of
adaptation to allow the move. So, right now I don't want to care about
what part of a file should be here or there, but what files have
something that should be featuring umit.common instead of somewhere
else.
Then we should introduce a new module (probably a singletone class)
to keep save the name like ".umit", verbose level, version etc.
I think I didn't get this part. You mean to have another module to
save those files featuring umit.common or somewhere else?
umit.core.BugRegister
Ok! But it need some changes because it use version.
umit.core.CronParser
Ok
umit.core.Email
Ok (It depending of UmitLogging)
umit.core.GetConfigFile
It depending of umit.core.Path. Then I think, what is the propose of
GetConfigFile?
But it is from Umit Network Scanner.
umit.core.I18N
if LOCALE_DIR lives in common fine!
umit.core.Scheduler
It could be done but the Scheduler is for Nmap Scans. So it should
keep in umit.scan.core
The part of the scheduler that should be of interest of other
projects, is the ability of scheduling tasks. The Scanning part should
be, indeed, placed inside umit.scan.core.
umit.core.UmitLogging
Yeah but it need something to detect verbose level as I refer above.
It can be simply a Base Class that other projects import and set those
things.
Should be moved from their current place into umit.common, and other
stuffs like regular expressions should be moved out from some files,
and feature an specific umit.common file as well. For example: regex
to evaluate if a given string is really an IP address. That's
something that can be potentially used by other softwares, and I bet
you can come out with more regexes and files like these.
About environment development, where should live umit.common?
A third party is a good idea like: trunk-common.
I think that our repository will need to face some drastic changes as
well. For example, I think that our network scanner should move from
trunk to trunk/umit or trunk/ns. That's something to be decided in
another thread after we decide on umit.common ;-)
Besides those listed, I think that *perhaps* the NmapCommand and other
Nmap related code should somehow feature umit.common or
umit.common.something as I think that other projects may use Nmap in
the future. What are you opinions on that also?
Kind Regards,
---
Adriano Monteiro Marques
http://www.thoughtspad.com
http://www.umitproject.org
http://blog.umitproject.org
http://www.pythonbenelux.org
"Don't stay in bed, unless you can make money in bed." - George Burns
------------------------------------------------------------------------------
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
