I agree with Klaus here, one thing is about the CIM and WBEM tools and the other is reinventing our own model. The CIM model is quite complete, and we should try to come up with something following its philosophy. About SCR, yes, creating agents is not something intuitive, specially if it is not a simple inherited ini file agent, but a full YaST component. After all the interesting we discussed with Klaus during the week, I have been thinking a lot into all those problems, and started looking for solutions. For example, playing with a little of Ruby sugar, I managed to replicate SCR in a interesting way: Lets see how do I define an agent: Plugin.define "release_agent" do author "Duncan" version "1.0.0" extends :agent run_before :other def read(path) if path == :'.system.product.edition' f = File.open('/etc/SuSE-release', 'r') f.each_line do |l| return l end return "" end end def supports_path?(path) return path == :'.system.product.edition' end end puts SCR::read(:'.system.product.edition') done. Why is it so hard with our tools, because we reinvented everything. (Note, the example implementation of a SCR engine is 26 lines of code, not shown above) Note: the above example is even compatible with the old scr, as any path is passed down to the old SCR. Require the wbem module and you can add wbem access, require drb and you can call distributed code. Now, our main problem is that we have to interact with quite a lot of code in different languages, ages, paradigms. We have our own component model, but it is quite complex. We could go our way and implement all the YaST basic core in Ruby or Python and add nice stuff like WBEM access, access to services in the web, etc, but we need a nice way to reuse and use functionality from C/C++ code, Python, Perl, etc, and the other way around. Especially if we are dealing with the system, you don't want the developers to learn how to create ruby extensions or python modules just to interface with some low level library. We depend or will depend on that (if we plan to ditch everything inhouse that is a reinvention). We have that component model right now (liby2) but try to create a component yourself, isn't that the reason why libstorage uses generated perl swig bindings, to interact to the component model via the super complex perl-bindings. I was giving a look at solutions out there. One I found was OASIS Service Component Architecture / C and C++ (SCA-C-C++) which has a implementation by Apache called Tuscany, already in the 1.0 Milestone3. Its a service model, more oriented to web services but supporting local components. The approach is pretty simple, a service in c++ is just a .h defining the interface, the implementation, and a wsdl file. You can implement them in python and ruby (services and clients) and that is supported by the runtime out of the box. There is an article at IBM DeveloperWorks [1]. Going back to SCR. I don't think the syntax sugar is very important, but how we use existing knowledge there. The CIM model is a place to start, but there are also issues that are not intuitive. The CIM model is just a OO way of looking the system, where you ask for instances of a class, and then use the objects properties and methods. If you ask the CIMOM for the instances of CIM_UnixFile, you get the root tree /, in my experiments, I had no clue how to go forward and do _SIMPLE_ stuff like reading, globing, etc. (not to mention it took 10 seconds to read 10 directories in / but probably it was ruby::wbem fault). However, stuff like getting the numbers of CPU, the installed products, etc. CIM provides a model much more consistent than the low level greps of /proc and the package bindings, but some models like accessing files are not nice. (An argument could be that we should not access files, but I am not sure about that). The big question when prototyping all the ideas floating out there is, how to move on. Now there is some momentum, and the right time for other pieces (for example, the great YaST UI being decoupled). If anyone has a concrete experiment to try next, speak on! :-) Duncan [1]: http://www.ibm.com/developerworks/webservices/library/ws-soa-capisca1/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org