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: [email protected]
For additional commands, e-mail: [email protected]
