EXECUTIVE SUMMARY: - want new libstorage - can't simply get a drop-in replacement - have to handle target map somehow - want a wrapper for the target map - replace the interfaces for that wrapper when new libstorage is ready DETAILS: As most of you probably already know, we want a new, much improved libstorage. Not only will this clean up about 15 years worth of legacy (a.k.a. cruft), it will also remove quite a number of limitations of the existing code and architecture. Many of those limitations are blockers for features (or for fixing bugs) that get requested again and again. We have a long, ever-growing list of such features and bugs. But getting a new libstorage is only half of the story (or even less); the rest is about using it in all the existing code like in yast-storage (storage proposal for the installation; expert partitioner) or yast-bootloader. Most of that code also got auto-converted from YCP to Ruby which did not exactly make it any prettier; that's natural for such an automated conversion, but still we should start turning it into real Ruby code that meets our criteria for code quality at some distant time in the future. We don't want source files with 7000 lines of code any more. We don't want functions with 500+ lines. We don't want it to rely heavily on (file-) global variables. We don't want monstrosities like that "target map" being accessed and modified all over the place. Personally, I would very much like to refactor the storage proposal stuff; I'd like to have clean, nice Ruby classes that can be properly unit-tested (without formatting my hard disk) and that are well-documented. Arvin already made a new libstorage implementation during one of the hackweeks (last year?) that looks very promising, but which is still incomplete. We don't want to let bit-rot take over until this becomes a total wreck. We already have a number of backports for that. Right now, getting to those goals is very difficult; we can't just put a stop to all features for upcoming releases, much less L3 calls or high-priority bugs. So we can't just implement the new libstorage completely, create the proper unit tests, and convert all of the existing storage-related Ruby code to use it; this might easily take half a year or more. This is getting more complicated due to the way libstorage is used in the existing storage-related Ruby code (inherited by the old YCP code): It heavily relies on a data structure called "target map" which is a deeply nested data structure to represent disks, partitions, RAIDs, volume managers and whatnot. This target map is used all over the place, it (or parts of it) is handed over from one function to the next in all that code, parts are extracted, deleted, added, modified, uglified, whatever. That target map is the pivotal part of all that code. This is bad because it's not that obvious when, how and why it is used everywhere. But it's also good because it provides us with an abstraction layer between libstorage and the Ruby world. So, to get anywhere at all in the forseeable future, I propose to start refactoring at that place: I'd like to have a Ruby class that wraps that target map. For starters, I'd simply put the existing map into it (in the constructor and in a setter method) and get it out again, then begin to add methods to access all the individual parts of it - real methods, not just accessing map keys and values. And use those methods in the appropriate places, of course. When some time in the (hopefully not so far away) future the new libstorage gets ready, we could simply change that wrapper to use methods from that new libstorage. This should be transparent to the other code. Yes, I know, this approach is not as clean as a complete rewrite. We might end up with some other legacy code in the process (but if we do it carefully, we should be able to minimize that). It will mean additional work that would not be necessary with a complete rewrite. But then, I believe it is unrealistic to ever do a complete rewrite and put all other development or maintenance in the storage area to a complete halt. If we ever want to get anywhere, we will have to take this approach. How do you get over a mountain? Not by whishing it wasn't there at all. No, you take one step. Then you take another. And another. And another. And at some time, you will find the mountain is behind you. This should be the first step crossing that mountain. Thoughts? Ideas? Bitching? Rants? Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org