Duncan Mac-Vicar P. write: > > 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
Maintenance nightmare.... E.g. I don't have problem to maintain projects in different languages ( now RoR, perl and YCP), but if I am maintaner and someone leave or move to another team and need to start maintaining new module which is in new language I spend some time to learn it and it is not good idea to have weak knowleadge of many languages. I think we should choose one language ( it is not important if it is python, ruby, perl whatever), but we should stay with it as then it is easy to learn just how module work and not need to know how language work. And because many people in team work aslo on RoR then I think ruby is good choice as we have good knowledge for this language. Of course we can create bindings and allow community to write own parts, but we should keep one language so we can easily maintain many years after people leave company. > - 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) Yes, I agree. For me the best way should be to told what type of data I have and then let UI library to decide it like RoR auto forms > - Make easy to get data and to write data. Absolutely agree. For me concept of models from MVC is fine as it loads and store models in well defined place and if we use object language we can benefit from inheritance for similar data ( it is not important if public or private inheritance). Pepa -- Josef Reidinger Appliance Toolkit team maintainer of perl-Bootloader, yast2-bootloader and parts of webyast and SLMS -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
