Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
Stanislav Visnovsky write:
On utorok 01 Február 2011 11:31:40 Johannes Meixner wrote:

On Jan 30 14:35 Stanislav Visnovsky wrote (shortened):
On piatok 28 Január 2011 16:50:10 Arvin Schnell wrote:

1) Replace YCP with some common language? With more that 100

modules this looks impossible.

I think this is a good and the only viable option if YaST code
should survive in long run.

For me this looks like a contradiction in itself because
killing YCP would kill all code which is written in YCP.

what did you actually mean?

I mean YCP as programming language here. The only viable alternative is to ,
as you write below, phase it out:

I agree.

1) introduce single alternative common programming language as 1st class

Maybe it could be interesting to define our requirements on language. from my
POV it should:
1) be easy testable
2) high-level ( in general we don't care about programming language performance
as we do many time consuming tasks and if we need good performance in some part
then use bindings (see below))
3) easy debugging (it is really annoying debug ycp via debugger)
4) easy profiling (it is hard to find bottle neck)
5) easy bind libraries, especially in C and C++
6) object oriented with exception ( it is related to 2 as it would be great if
we can easy share object ( now we share functions and global variables and it
is sometime really pain. Exception is good for error handling. It e.g. allow
easy decide if error is from user or programmer and allow proper error message)
7) have at least medium community and codebase so we are not alone to maintain
it or be one of two maintainers
8) be enough mature, so we don't need to fight with language
9) allow easy sharing code like python eggs, ruby gem or perl cpan so we can
share our work where it make sense and have more users ( or easy use same code
also in other our products - just try remember if other our product use any
code written in YCP)

2) move the codebase from YCP to this language, doing easy refactoring tasks
where applicable (keep YaST as whole working)

Also for codebase have good test coverage and clear purpose of all methods.
Also sometime clean public API could be good (try to keep it simple :).

3) deprecate YCP as programming language

Yes, make sense.

4) look at architecture from perspective of the new codebase and new language

Absolutely make sense, especially reconsider if we need SCR agents
architecture. Also consider better MVC model then now. Especially if we want
share model there should be no UI calls.

I'm fan of small steps, not grand plans for redoing everything from scratch.

agree, small steps which is finished is better then grand plan which is never
finished completely

Actually, I'm willing to contribute as time permits.

I can help with codebase and do code review :)



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
This Thread