I do prefer this process.
On Tue, Jul 28, 2009 at 3:38 PM, Adriano Marques <[email protected]>wrote:
> 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
>
>
------------------------------------------------------------------------------
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
