I would suggest a step by step "reborn" instead of a "replace by something we will write from scratch someday but does not exist yet". Taking the bests parts of it (libyui) plus support for a couple of more popular languages, and rethinking some parts like SCR, or how to access native system libraries or more radical approaches how a developer could implement a configuration dialog/wizard would allow for a step to step move to a YaST3 without throwing everything out (just like YaST to YaST2 happened). Forget about deciding if you build on top of CIM, augeas, libsilverbullet, etc. They are all projects with different layers of maturity, different levels of usability and solving very different use cases: ie CIM is high level but it is not very useful, and augeas is very useful but is is very lowlevel. Why not going for more flexibility to make a Linux expert experience when writing a module something that does not require for him to learn too much specifics: e.g: if he knows CIM, make easy for him to get a CIM property, but that he can easily use a augeas expression to get a config value, etc. So "taking what we know already" feels to me a good strategy: - Use a couple of languages people know and like - Allow to write dialogs and forms without learning extra stuff (after joe's request I did a prototype to show forms written in html5 using libyui :-), as they have metadata for validation and other stuff) - Make easy to get data and to write data. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org