On Mon, Jul 27, 2009 at 2:31 PM, Adriano Monteiro Marques < [email protected]> wrote:
> 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. > Sure! I was thinking in a more low-level. > > > 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? > Just look the BasePaths and Paths. There is a "umit" word in all part. > > > > >> >> 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. > Yeah. It is what I was thinking. > > > >> >> 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. > "I think I didn't get this part. You mean to have another module to save those files featuring umit.common or somewhere else?" ;) > > > >> >> >> 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 ;-) > Oh! Finally. I agree totally that some changes need to be done in svn. > > 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? > Yes and NmapOptions. > > > 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 > > Best Regards, -- Luís A. Bastião Silva
------------------------------------------------------------------------------
_______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
