Mailinglist Archive: yast-devel (177 mails)
| < Previous | Next > |
Re: [yast-devel] Direction of YaST Architecture?
- From: Josef Reidinger <jreidinger@xxxxxxx>
- Date: Tue, 1 Feb 2011 12:48:57 +0100
- Message-id: <201102011248.57954.jreidinger@suse.cz>
Stanislav Visnovsky write:
I agree.
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)
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 :).
Yes, make sense.
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.
agree, small steps which is finished is better then grand plan which is never
finished completely
I can help with codebase and do code review :)
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
On utorok 01 Február 2011 11:31:40 Johannes Meixner wrote:
Hello,
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.
Stanislav,
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
citizen
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 :)
Pepa
Stano
--
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 > |