On 29.1.2010 02:04, stefan.eisenwiener(a)freenet.de wrote:
I have tried to renew the greman webappearance of YaST (because it was the oldest
Now I am needing some help. I'm getting to the developers documentation, and
somethings don't make sense.
-- basic YCP questions
1. Why do we need YCP. (an other scripting language would have done the same trick)
That's for historical reasons, we have too much code written in YCP. Rewriting it
into another language would require much effort without any real advantage.
But YCP is not mandatory anymore, you can write a YaST module in Perl, Python, Ruby
or even in C++.
2. Why is YCP type based.
This prevents from some runtime problems, like passing wrong argument type.
Such errors are found during compile time.
The problem is that YaST is an installation system and when such an error occurs
during installation (in some corner case, or on a specific HW) the installation
simply crashes and user have non-functional system. We really had such a bug in the
past and fixing it is not trivial, esp. if it's found when the product
3. What is the use of Symbol and Trem Datatypes in
YCP. (not the format)
Symbol is like an enum, term is a symbol with additional arguments.
4. What is the use of Byteblock Datatype.
Byteblok is a raw binary data which cannot be displayed directly on a terminal (like
PNG image data). Currently it's not needed, IIRC it was needed for passing an image
to the UI. Now the UI's can load images directly from a file.
-- Modul design question
Why is the SCR concept not used like it was defined in the documentation, to be the
According to the Tutorial one should write a global API of the Modul to access data the
Modul works with.
This HACK would be redundant if SCR like described in the documentation, would provide
The SCR is low-level library, a Module cannot directly read files or access the
system (execute commands, etc.). It has to use an SCR agent for that.
(Well, that's valid for YCP modules, in other languages you can of course use
read/write system functions. But the same concept should be used also there
so it's unified.)
I hope this helps, if you have more questions just ask.
SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz
Lihovarská 1060/12 tel: +420 284 028 960
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org