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.m... [2] https://en.wikipedia.org/wiki/Coupling_%28computer_programming%29#Procedural... -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org