Dne Thursday 15 of November 2007 18:35:23 Klaus Kaempf napsal(a):
* Michal Svec
[Nov 15. 2007 18:05]: On Thu, 15 Nov 2007, Klaus Kaempf wrote:
I scanned all files below /usr/share/YaST2/{modules,clients,include} grepping for "SCR::". Just to get statistical relevant data, not for complete coverage.
The goal is to get relevant data for a SCR redesign to be implemented in parallel to the current SCR and have modules converted over time and shut down SCR is some distant future.
May be a dumb question, but which problems are we trying to fix?
I see sevaral problems
- Code cleanup / refactoring SCR is not fully understood by developers (coding all kinds of workarounds) and incomplete in some regards (developers parsing files in ycp). This should be fixed.
- No / Inconsistent modeling The pathes and data structures used in SCR effectively define a model. There is no clear documentation nor consistency in this model. Should we make the SCR model consistent or pick up an existing one (i.e. HAL for hardware probing or CIM for everything)
- Reuse of existing code For historical reasons (non-GPL license of YaST), SCR agents don't use existing implementations for instrumentation. For Code11, we have the requirement of 'friendly coexistance' with CIM instrumentation. A resonable combination would be to replace agents with existing CIM provider code.
- Separation of rights Security and 'role based' considerations recommend to separate the controller code (WFM in YaST) from the backend (SCR in YaST). The controller code should run without root rights, the backend code should assume root rights on demand (i.e. rpm -qa does not need root). This requires a redesign of the SCR backend.
Also, are you suggesting a completely different SCR(-like) approach or just "fixed" and more unified paths?
Thats what I'm trying to find out and get more input from developers.
The current thinking is to implement a completely different approach while keeping the current SCR in place and migrate modules one-by-one.
This is something which we already tried with LiMaL. The actual result is that we have two "standard" ways to access system. If we decide for any new approach, we should decide for an existing standard. With the requirement for code reuse, CIM seems to me to be the way to go provided we get reasonably over the coding overhead. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz