Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] SCR usage statistics.
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Fri, 16 Nov 2007 10:26:38 +0100
  • Message-id: <20071116092638.GA6846@xxxxxxxxxxxxx>
* Lukas Ocilka <lukas.ocilka@xxxxxxx> [Nov 16. 2007 10:11]:

Sounds great!

Nevertheless I don't see *any* benefit when comparing to the current
implementation.

For an experienced YaST developer doing single systems management and not
taking Code11 requirements into account, I fully agree. There is no
benefit.

But I do see (as mentioned yesterday), code cleanup, consistent
modeling, reuse of existing code, separation of rights and object
orientation as huge benefits.

What I see are these drawbacks:

* 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, ...).

Let me cite my previous mails

"The goal is to get relevant data for a SCR redesign to be implemented
in parallel to the current SCR and have modules converted over time
and shut down SCR is some distant future."

and

"The current thinking is to implement a completely different approach
while keeping the current SCR in place and migrate modules one-by-one."



* Confuses developers - currently we have clearly written: 'Read',
'Write', 'Execute' or 'Dir'.
The proposal of replacement for SCR::Read vs. SCR::Execute is almost
the same:

any cmd_out = client.foo.bar ( v1 )
any value = client.foo.bar

any cmd_out = SCR::Execute (.foo.bar, v1)
any value = SCR::Read (.foo.bar)

So what do you propose ?


* It's not a fun to rewrite all the existing code :) ;) and it's not
easy either! ;)

See above.


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.

Thats an important aspect. Thanks for bringing it up.


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.

We already have this distinction with SCR::Read(.target ...) and
WFM::Read(.local ...) ?!


IMO: All in all, this is not worth changing. But please, convince me it is.

I'll try ;-)

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups