Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] SCR usage statistics.
  • From: "Duncan Mac-Vicar P." <dmacvicar@xxxxxxx>
  • Date: Mon, 19 Nov 2007 10:01:33 +0100
  • Message-id: <200711191001.34638.dmacvicar@xxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >