On 02/10/2011 09:25 AM, Thomas Goettlicher wrote:
On Thursday, February 10, 2011 02:50:46 pm Robert Schweikert wrote:
Without a clear picture of the architecture that everyone can work from you end up with something that is cobbled together and the pieces never fit properly.
The implementation steps should be on the smallish side, no question. But there ought to be a big picture showing the "macro architecture" if you will, maybe something like the attached diagram.
The everyone can work on their own little piece of the world but with the big picture in mind. That way things will fit together. Having something like this ought to make it easier to make decisions about the moving parts.
Robert
Your attached diagram looks similar to the overview designed by jdsn and me:
+---+---+---+---+ +--------------+ | Q | N | g | c | |webyast client| | t | C | t | m | +------+-------+ | | | k | d | | +---+---+---+ | http | libyui | | | +-----------+ +-----------+---+ +------+-------+ | lib shell | | yast modules | | rest service | +-----------+--------+---------------+----------+--------------+ | common lib: reads/writes config files, starts/stops services | | integration of polkit and zypp | +--------------------------------------------------------------+ | SYSTEM | +--------------------------------------------------------------+
Perhaps rest service should sit on top of yast modules.
I am not sure what to make of the common lib and whether the additional indirection is needed. Why would a YaST module not write the configuration files it is responsible for directly? I suppose "lib shell" is the API for scripting? If yes, that would appear to be too close to the point where the rubber meets the road. IMHO we want scripting to occur on top of the YaST modules and ideally have the YaST modules setup such that they can be imported into whatever language we end up with. As shown in my implementation proposal in Python import yast3.NAME_THE_CONFIG_MODULE and then have the domain specific interfaces available as in yast3.ntp.setNtpServer(....) In short I see the introduction of the "common lib" as a very big difference in the architecture diagrams. Note that I am not saying that there is no code that may be shared between some or all YaST configuration modules. All I am saying is that there is probably no need for another level of indirection. Code common to some or all YaST modules (such as the modified file detection for example) can be shared if this common code is simply implemented as a module at the same level as all the other YaST configuration modules. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org