Hello, On Jun 20 12:51 Klaus Kaempf wrote (excerpt):
* Johannes Meixner <jsmeix@suse.de> [Jun 20. 2013 10:52]:
Regardless how it will be implemented, what you say is basically:
Even after YCP was replaced by Ruby in YaST, arbitrary contributors cannot just do Ruby programming as usual to contribute something to YaST.
Exactly. You still cannot use 'puts' or 'printf' to output a string to the UI, you need UI-specific calls. And the backend is no difference.
No programmer expects that 'puts' or 'printf' must work to output a string to a graphical UI. The UI calls in YaST provide the obvious advantage that the programmer does not need to care about the details of the actual UI that is used by the user (ncurses / Gtk / Qt). I.e. one same code for all those UIs (by the way: this is the only thing that I really like about YCP). In contrast the YaST concept of a backend running on the target system while the actual YaST program runs on another system does not provide an obvious advantage for the programmer because first of all it makes programming more complicated because one cannot just do the usual calls to read from and write to the system.
Where I agree with you, is the need to explain to contributors the reason behind this decision.
Is there perhaps already documentation available so that novice contributors would understand the reason behind?
Therefore I like to have it discussed here in advance if it is possible to drop the whole idea behind SCR.
And replace it by what ?
I wrote "drop" because I meant "drop".
Ruby printf to write (arbitrarily complex) config files ?
All contributors are forced to use an artificial looking abstraction layer in any case even for reading and writing really simple stuff (that works everywhere except in YaST) ?
The idea behind SCR was to provide a simple API hiding the complexity of config files from the programmer. I strongly believe this idea is still valid.
This is another different idea behind SCR. But this is not what I was talking about. Generic calls to read and write config files would provide an obvious advantage when the programmer does not need to care about the details of his particular config files (as long as the config file syntax is sufficiently simple that those generic calls actually work correctly). But I know that the SCR INI agent destroyed the cupsd.conf file several times (the cupsd.conf syntax is not too complex) during the time when the YaST printer module was made by YaST developers. Theoretically it is perhaps possible to use the SCR INI agent to modify cupsd.conf but in practice the YaST developers failed to do so. This indicates that in practice there is no such thing as "a simple API hiding the complexity of config files" when the config file syntax becomes a bit complex. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org