Mailinglist Archive: yast-devel (79 mails)

< Previous Next >
[yast-devel] old libstorage design decision
Hi,
when I thinking about current design discussion and design of new
libstorage, I think it helps if we know what is problem with old
libstorage that prevents its evolution and require revolution like
rewrite.

So is there any link where is documented which design decision leads to
problem in old libstorage? I try design-decissions.md but it is just
result of new decision, but no retrospective on old one. I see
something in [1] but I miss there what prevents evolution of code that
remove limitations of data structures, why all data cannot be
exported/imported, why cannot be introduced exceptions, why API cannot
be consolidated to new interface. Why monolitic code with
very long functions cannot be refactored to small ones. Only one design
decision which I see there is that problem is that heavily relies on
"target map" which contain all storage-related data. So I see there is
a problem that all code is tightly coupled with target map data
structure ( known as common coupling [2] ) which leads to solution that
now there is still high coupling on device graph, but its data
structure is more hidden, so it depends on smaller API then before (so
now it is External coupling or Stamp coupling depending on given code
which is one or three steps better ).

So I believe that new code wants to prevent to get to such state where
evolution is not possible and it can bring some light to some design
decision rationale and can helps others understand it.

Thanks
Josef

[1]
https://github.com/openSUSE/libstorage/blob/master/doc/status-current-code.md
[2]
https://en.wikipedia.org/wiki/Coupling_%28computer_programming%29#Procedural_programming
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
  • No further messages