Hi! On piatok 28 Január 2011 16:50:10 Arvin Schnell wrote:
Hi,
in a recent telco the question about the direction of the YaST architecture was raised.
In the pase a lot of things have been tried. E.g. integrate different languages (Perl, Python, Ruby), try different build systems (cmake), automatic generation of bindings for C/C++ libraries (libstorage) or simply use common technologies (e.g. CIM). This is not necessarily bad but from my point of view quite a few ideas are stuck halfway (Python integration) or are simply of bad quality (generation of bindings). Even usage of Perl seems to be considered to be no improvement.
But instead of removing failed approches we keep them and often do not even look at better ways. As a result the YaST architecture is on one hand more complex and confusing then required and on the other hand lacks quality and features.
So now that we have minimal recourses to improve the YaST Architecture we should concentrate on a few improvements instead of dissipate our energies again.
So what seems desirable and feasible? Some ideas:
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. The knowledge of YCP internals is slowly forgotten and the language is stalled for some time now.
2) Allow a common language next to YCP? A good integration seems difficult.
I see this as step towards goal 1).
3) Improve YCP (at least fix bugs)? Do we want that?
What kind of bugs do you see in YCP? There is only a couple of them I'm aware of and they can be easily workarounded. In this regard, I don't think it's worth trying to fix them.
4) Better bindings of C/C++ libraries for YCP?
What's the goal of this option? Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org