Mailinglist Archive: yast-devel (26 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
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: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups