On Friday 16 November 2007 10:11:49 am Lukas Ocilka wrote:
Nevertheless I don't see *any* benefit when comparing to the current implementation. What I see are these drawbacks:
I agree, we should not focus on the syntax sugar, but on the model.
* Broken backward compatibility - and we know we need backward compatibility in such important tasks as access to system is. We just can't rewrite the whole YaST overnight (OES, SLEPOS, ...).
Yes, we can. Released products use released version of YaST, that we have to maintain, but we have to maintain it anyways as much as we maintain the old package manager library which is a different approach as SLES. We should not. Rewrites aren't good ( http://www.joelonsoftware.com/articles/fog0000000069.html ) but one thing is renewing our platform, the other is rewriting. You can write new ways to use the platform, and reuse old code (like SCR agents for example).
* It's not a fun to rewrite all the existing code :) ;) and it's not easy either! ;)
We don't want to rewrite. But we don't want to rethink anything too. We have human barriers in the product. We, the developers, are so used our smelly bunch of tools and base technology, that we refuse to think on a platform other people would like to use too. Can we enable other to use YaST and at the same time keep our users saying that YaST rock? I think we can.
The current SCR implementation expects caching the changed values, all are written to disk at once to make it faster. I don't see any clear /object-oriented/ syntax to rewrite it to be still understandable.
I don't consider the syntax sugar important at this stage, and you are right, sometimes adding OO without reason can transform something simple into something verbose. I see the OO power more important in the agent development (see my other post).
Anyway, if we are talking about SCR -> 'client', WFM would need to be 'system' or something similar. Which, on the other hand, would bring another confusedness.
Lets try to brainstorm this in the other way, instead of finding out why something will not work, lets try to find a _different_ approach that would work.
IMO: All in all, this is not worth changing. But please, convince me it is.
Just try the exercise of trying to explain somebody how to create an agent which is not based on the sysconfig or ini one.
PS: The current documentation of SCR agents is generated from sources for every release. See these pages, for instance:
SCR: http://forgeftp.novell.com/yast/doc/SL10.3/scr/index.html http://forgeftp.novell.com/yast/doc/SL10.3/scr/136.root.wgetrc.html http://forgeftp.novell.com/yast/doc/SL10.3/scr/152.sysconfig.SuSEfirewall2. html
SCR how-to document: http://forgeftp.novell.com/yast/doc/SL10.3/tdg/documentation_SCR.html
You see that every agent documentation is one line, and how to create an agent is a copy paste of a ini based agent, which confirms my theory that we are unable to explain humans how to do anything more complex than that :-) Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org