Dear Travis, We clearly disagree in this area. I hope me explaining my perspective is not seen as unhelpful. On 07/09/2015 07:00 PM, Travis Rhoden wrote: >> (2B) inflexible / complex include paths for shared code between facade >> > implementations. >> > > I disagree here. There are plenty of places to put code that is common and does not have to be duplicated. I definitely don’t want code in each host module that knows how to deal with systemd. The code that does have to be in each host module is how to detect/assign what init system is being used, and how to call into the appropriate (common) module to do what it needs. > > As for complex include paths, I’m not sure I have much of an argument here other than to say that all frameworks have their conventions. I don’t see what we are doing as anything different than what is enforced/recommended by many frameworks/scaffolds popular in Web app and MVC paradigms like RoR, Pyramid, Django, etc. It’s just convention to learn. I don't understand why you chose to defend this. Please expand your argument. I will not go into the negative side effects of importing modules as objects in the include paths, as a work around for potential side effects of our current façade model, as this topic is more complex than the points I do raise in this email, but I will expand them should these arguments not be valid, as I would like to understand where we intend to go, and how we minimise long term maintenance and maximise extensibility. Here are the simpler reasons why I don't agree: I hate the enforced code structures used my many "popular" frameworks especially common in web frameworks but I accept that these enforce very clear standard design patterns that are known to scale and be extensible and you acknowledge this difference to the ceph-deploy code base simply by calling them MVC. * Having enforced relative paths between code files defined by the implementation of the code is a great limitation. While one can place code modules in the correct location if only one thing defines the correct location, one can easily get into difficulties 2 obvious limitations in tolerating this are: (1) by having two parts of the code base enforcing relative paths between modules. (2) by having relationships between modules become needlessly complex because the enforced relationship says the code must go in a place that is not correct to solve the problem. (this is analogous to the death of hierarchical databases and their replacement with relational databases) So since the issue is most serious if you have 2 components in the code base that "enforce" module layout, and we only have one, we are only preventing further components that "enforce" module layout. Admittedly neither of these issues has _prevented_ development on ceph-deploy so far, or led to duplication now you withdrew your comments about all façades being the same. Due to the façade defining module location we so far have, some things have become confused in where the module can be placed that are clearly OS specific. Examples include: ceph_deploy/util/constants.py which is clearly includes constants that are OS specific, such as package names. ceph_deploy/util/pkg_managers.py which clearly is a set of OS specific implementations. Both of these lead to unnecessary complications, when they could be façades in their own right and should have the modules moved if we continue to have this enforced module location in the façade implementation. This inconsistency will not effect customers but does effect the clarity of the code, and leads to more conditionals than we might have if we took in my opinion a cleaner implementation to our model. I will _not_ provide sample code of improvements, as this may lead to people discussing irrelevant issues, until this point is resolved as my mistake, or an area that is agreed can be improved. Best regards Owen * It is one the many reasons I abandoned django in favour of Pyramid for my personal projects, even though django only enforced separation of components Model View and controller, pyramid to my recollection (its been 3 years at least) only recommended a module relationship path . -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
