On Fri, Feb 27, 2009 at 10:12 AM, Guilherme Polo <[email protected]> wrote:
> On Fri, Feb 27, 2009 at 9:52 AM, Francesco Piccinno <[email protected]> 
> wrote:
>> 2009/2/27 Rodolfo S. Carvalho <[email protected]>:
>>> On Fri, Feb 27, 2009 at 8:52 AM, Guilherme Polo <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> Can we move to a cleaner namespace in umit ? I'm hoping to change it from:
>>>>
>>>> umitCore
>>>> umitCore.radialnet
>>>> umitGUI
>>>> umitGUI.radialnet
>>>> umitDB
>>>> umitInterfaceEditor
>>>> umitInterfaceEditor.selectborder
>>>> umitInventory
>>>> umitPlugin
>>>>
>>>> to:
>>>>
>>>> umit
>>>> umit.core
>>>> umit.core.radialnet
>>>> umit.gui
>>>> umit.gui.radialnet
>>>> umit.db
>>>> umit.interfaceeditor
>>>> umit.interfaceeditor.selectborder
>>>> umit.inventory
>>>> umit.plugin
>>>
>>> I agree totally with this structure. I like the idea of having a
>>> 'umit' central package.
>>> Additionaly, for UmitWeb, we can have the extra packages:
>>>
>>> umit.web
>>> umit.web.views
>>>
>>
>> Me too but I think that would be better that interfaceeditor is a leaf
>> of gui, like also inventory. For plugins i suggest that core and gui
>> part should be separetad, so the gui part will be included directly in
>> umit.gui while the core part will be umit.core.plugin.
>
> Uhm, maybe. But this kind of change requires better planning.
> umitInventory doesn't fit entirely into umitGUI, so I'm not sure why
> you are suggesting to it be entirely inside umit.gui. I also believe
> interfaceeditor doesn't fit entirely inside umitGUI, but I'm not
> suggesting anything since I haven't looked at its code.
>
> The first step is moving to a cleaner package structure, next we can
> decide how to restructure those packages -- if needed.
>

Also, why continue the "abuse" in umit.core ? Why do you think
umitPlugins should get some code moved into umit.core ? umitCore
already contains an enough mix of core and non-core modules, please
lets not continue with this. I hope umit.core (or umitCore) at some
point only contain the real core modules, Email is certainly not one
of them, neither Scheduler things, neither Plugins things.

>> The final
>> result should be:
>>
>> umit.core
>> umit.core.radialnet
>> umit.gui
>> umit.gui.radialnet
>> umit.db
>> umit.gui.editor
>> umit.gui.editor.selectborder
>> umit.inventory
>> umit.core.plugin
>>
>>>>
>>>> higwidgets stay as it is, except for some files.
>>>> higwidgets.higanimates for instance is nice, but how come that got
>>>> inside higwidgets ? For this kind of widgets we could add a
>>>> umit.gui.widgets.
>>>
>>> I guess higwidgets is a separated project, owned by Cleber, but we
>>> need to take a look on that.
>>>
>>>>
>>>> Then there is the remaining issue about the umit executable file and
>>>> this new umit package. We could move all the code currently in this
>>>> umit file to a module named main inside this new umit package. The
>>>> unix installer could then create a umit executable (which could be
>>>> either a shellscript that executes "python /path/to/umit/main.py" or
>>>> something else that imports main.py and run main(sys.argv)) at the
>>>> appropriated place.
>>>>
>>>> My motivation to do this namespace move is that Umit is limiting
>>>> itself to very few packages, files related to the scheduler could move
>>>> to another package, umitInventory could be split too (and it would be
>>>> good to so). I'm also planning to create something to merge
>>>> configuration files and it would live in another package, since I
>>>> don't think it makes much sense to place it in any of the existing
>>>> packages.
>>>> Another point to consider is that it pollutes site-packages for no good 
>>>> reason.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> -- Guilherme H. Polo Goncalves
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, 
>>>> CA
>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the 
>>>> Enterprise
>>>> -Strategies to boost innovation and cut costs with open source 
>>>> participation
>>>> -Receive a $600 discount off the registration fee with the source code: 
>>>> SFAD
>>>> http://p.sf.net/sfu/XcvMzF8H
>>>> _______________________________________________
>>>> Umit-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/umit-devel
>>>>
>>>
>>>
>>> Ok, +1 for the refactoring. We'll need to put some effort on it, but I
>>> think it'll worth it.
>>> --
>>>    Rodolfo Carvalho
>>>     Web Developer
>>> [email protected]
>>>
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>> -Strategies to boost innovation and cut costs with open source participation
>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> Umit-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/umit-devel
>>>
>>
>>
>>
>> --
>> Best regards,
>> Francesco Piccinno
>>
>
>
>
> --
> -- Guilherme H. Polo Goncalves
>



-- 
-- Guilherme H. Polo Goncalves

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel

Reply via email to