* Johannes Meixner <jsmeix@suse.de> [Feb 02. 2011 15:19]:
On first glance it seems you like to replace the YaST specific language YCP with another YaST specific language (which could be now implemented in Ruby).
Well, not quite. I want to use one well known, documented, and maintained language (e.g. Ruby) as a foundation and provide domain-specific functionality. Thats like LEGO with pre-assembled parts to construct larger stuff more easily. These parts make it easier to build (write code), understand (read code) and fix (debug code) your LEGO construct. And you still have the small LEGO blocks (underlying programming language) available for full flexibility. And there is a strong focus on 'understand' how something is constructed and what it does. Code is usually written once by one programmer but read many times by different developers.
Klaus, could you describe in more detail what you actually mean?
Perhaps you meant something like what I would like to have:
I do not care about the language.
Well, you do, sort of. You do care about the language to reflect your problem domain (YaST modules for systems management). You also do care about the language being flexible and well-documented to allow you to go low-level and code your own functions.
I do care about the ready to use set of functions (or classes or whatever such stuff is called in the particular language) which are provided by the YaST development environment so that I could implement my particular YaST modules easily.
When I learned YCP I was searching for its built-in functions to change the system (e.g. change config files and so on). But I found out that there are no such functions in YCP. On the one hand YCP is THE language to implement YaST modules but on the other hand YCP does not provide functions to change the system. Basically YCP is only about the user interface!
YCP evolved that way because the UI part had a full-time developer caring about the user interface. Originally, YCP was intended as the glue between the 'system' part (SCR) and the 'user interface' .
Then I learned about this other stuff how to change the system.
I do not care very much about how to implement the UI because I do not need sophisticated UI functionality.
I would be more interested how to change the system. I would like an easy to use framework to change the system (and not an obscure ini agent which destroyed config files).
And thats exactly the point. You don't want to have code like SCR:Execute("/bin/mkdir", ...) but system.mkdir ... because 'mkdir' is something easily understood. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org