This time, I don't want to commit the same mistake. We'll create a wiki
page, and write everything down there until we get things right, instead of
incrementing and upating things in this thread. Last time I searched for
details on the new namespace and what was decided in the end I almost went
crazy.

So, I created this page:
http://trac.umitproject.org/wiki/UmitCommon

We may continue discussing here, but we should accord to something and then
write the resolution in that page so it won't be hidden somewhere in the
threads. I already added all the files suggested in this thread.


Kind Regards,


On Mon, Jul 27, 2009 at 4:20 PM, Luis A. Bastiao Silva
<[email protected]>wrote:

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


-- 
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
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel

Reply via email to