Hello Rodolfo, > I choose the 'umit' namespace.
So, we are 3 by now (myself, Luis and you). >>> umit -> This is the base module name for the namespace. Don't forget >>> to put a __init__.py inside it, otherwise your imports won't work. >>> >>> umit.higwidgets -> We'll be moving higwidgets to this namespace as >>> well, for the same reason we'll be conducting that for the other >>> libraries like UMPA and Zion. >>> >>> umit.db -> Currently this module is inside umit.db in the trunk. It >>> won't be moved into umit.scan.db because it may be used by other >>> projects. >>> >>> umit.plugin -> The current plugin module should be moved out of pm and >>> umit, and be used by both through a unique namespace. Is that ok, >>> Francesco? >>> umit.plugin.geoip >>> umit.plugin.schemas >>> umit.plugin.traceroute >>> >>> umit.scan -> The scan refers to our scanning interface, which is Umit. >>> umit.scan.core -> Our current umit.core module >>> umit.scan.core.radialnet -> Our current umit.core.radialnet module >>> umit.scan.core.qs -> The Quick Scan core module >>> umit.scan.core.bt -> The Bluetooth Scanner core module >>> umit.scan.core.preferences -> The main Preferences Window module >>> umit.scan.core.preferences.actions >>> umit.scan.core.preferences.conf -> The conf module for Preferences >>> Window. Perhaps this should be merged into Umit's conf modules, our >>> something similar? Not sure if we need this here. What do you guys >>> think about it? > > Ok, I think I disagree about this structure map. I would choose a > simpler package structure. For example, in my case, I use the umitWeb > (soon it will be umit.web) package. The core classes are already in > the umit.web package, and I won't need an additional umit.web.core, > for example. I got your point. In umit.scan, we use core because we have gui. I never thought about having the core inside umit.scan and the gui inside umit.scan.gui. I just fell like this is a good practice to make things clear, although I can see any clear reason to avoid doing what you recomended but for the sake of having things more organized and clearly separated. When a user see core, he understands that there he will find only the core logic, and nothing else. But when they go for umit.scan, they could think that there can be anything. Of course we can write somewhere the rules, but I'm trying to provide a more intuitive thing, to avoid having people to read much in order to be able to use this. A friend of mine here at work told me that he was working in a company where code comments where forbidden. Everyone should always write understandable code that wouldn't need comment to explain it. Although I don't completely agree with that, I think that it is a good concept, because if people act like this, the people that will come next will understand things easier without the need of finding the proper comment or documentation to understand what's going on there. Sometimes we talk about usability here, in the sense of Interface and User experience. Now I'm talking about how to delight ourselves with a well organized namespace that is intuitive and easy to use ;-) That's the point of having things organized like I did (using core and gui, instead of only gui and leaving the core astray). > Ok, this is my 2 cents: I vote for a structure that is like that one > we already have: > > umit.core => core libs. I think this package is being used (and will > be used) for the most part of projects. If new functionalities can be > integrated, then it should be added to the umit.core. But I think > *here* we should put a 'scan' package, regarding to the network > scanner, the nmap interface. Then, umit.core could adopt this layout: > > umit.core > umit.core.scan > umit.core.bt > umit.core.qs > umit.core.future_core_projects Isn't it more intuitive to have umit.scan instead of umit.core.scan as we have umit.umpa, umit.zion, umit.pm and umit.web? I think it breaks the logic the way you're proposing. If we design, instead, umit.scan, umit.umpa, umit.zion, umit.pm and umit.web, we'll all know what things relates to. And that easy things while packaging also, because we can check the version for umit.scan instead of checking for umit.core.scan and umit.gui.scan and whatever else needed that could be inside umit.scan. If umit.scan represents our main scanning interface, then all things related to it would be inside it, not spread all over the namespace. > This way, the umit.core package would be a container to our 'core > technologies'. For the amount of projects we currently have, that may sound reasonable somehow, but as we grow that will prove not as efficient as having related things inside their own namespaces. If we choose to go by putting all core in a namespace, then all gui in another, and so on, we'll spread everything and make it harder to understand rather than easier. Think about the usability thing I told you before ;-) > Then, the web packet (I think it doesn't fit in the "gui" package): > > umit.web > umit.web.views With that I agree, and it makes some sense, indeed, if we consider Umit Web to be another separated project. Perhaps, having it inside umit.scan makes more sense because it is a scanning interface and it would user our core scanning technologies (umit.scan.core), doesn't it make some sense also? This way, if we have a web interface for pm, or whatever other project in the future, they would follow the same standard instead of having people confused and asking: "That umit.web is the scanning web interface or is the PM Web interface"? Just an example... But we'll certainly have other web based tools. Therefore I proposed the umit.scan.web, because people will think: oh! that umit.scan.web thing is the web interface for Umit Scan just as umit.scan.gui is the GUI iterface for Umit Scan ;-) > The database module: > > umit.db That one is an issue in the sense that as we grow, other projects will need different database designs. We could indeed leave there the main db manipulation modules, without any specific model or project bias, than each project would have its own umit.whatever.models, for example. What do you guys think? > So, the independent products, Like Zion, UMPA and Packet Manipulator > would reside directly inside the umit package: > > umit.umpa > umit.pm > umit.zion > > But I didn't get a concisious way about how put the GUI part of > umit.pm and umit.zion. We could brainstorm here about this model and > try to define some things. That is ok for zion in the sense of backend, not gui. For the same reason I explained above of avoiding having things spread all over the namespace. >> The conflicts with old versions should be *avoid*. So I was thinking about >> it, at least I didn't see any problems, not yet. > > I think we should work on setuptools-based installers. It should be > the best way to avoid this type of conflict. And another important > thing: Maybe we should adopt a way to idenfity the umit's version > inside each module (Like a $Version$ in the headers, or something like > this). This way, we could detect different versions, and give a clear > error message for the user. We actually will have to work on several fronts: Mac OS X -> macports with separated packages (umit.scan, umit.pm, etc.) Windows -> The installer will install everything needed in a separated place, therefore there is no need to worry with module conflict. Everything is self contained. Linux: Ubuntu -> We can use the same strategy that macports, by separating the packages. Red Hat -> Same thing, but with yum and rpm packages Other distros -> setup-tools Therefore, I think we would have to ship umit like this: umit.common.pkg umit.db.pkg umit.scan.pkg Please, understand pkg as either being a deb, rpm, macport, tarball, egg, etc. Then, umit.scan would depend on umit.db and umit.common in specific versions. If we have any conflict happening, the installed should be intelligent enough to install the new version in a different prefix and ask the installed app to use that place instead of the regular old one. As I said, no need to worry about that on Windows. But for the rest, we need to worry about it, even if we're using setup tools. I don't know how would it behave in this case, if another app is using the old version. Or, we must always ensure backward compatibility with our libs, and make it replace completely the old by the new. Perhaps this is the smartest way to go ;-) Thanks for your input Rodolfo! You've being helping us a lot on solving this matter. Although we didn't agree in some points here, I see your points and I wouldn't dare to say you're wrong. Indeed your idea is very valuable, I'm just concerned that perhaps we're with different perspectives of the problem. Let's try to converge to a good solution here! Thanks once again! Cheers! -- 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 ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
