Since the original thread is already ruined with discussions about concrete API design details that were not the main topic of my question, I will try once again from scratch. Do we need a layer between libstorage-ng and (the rest) of YaST? I think so. Why do I? TLDR; libstorage-ng is multilanguage (with a Ruby-agnostic API, to say the least) and YaST-agnostic. Therefore, we need a layer to close the distance between libstorage-ng and Ruby/YaST. The alternative is to have boilerplate code all along YaST (like downcast) and our own customization for the Ruby tools. If you agree, please say so. If you disagree, please provide counterarguments. Now the long version of my reasoning (and you know that "long" means in my case). ;-) A) Libstorage-ng API is designed to be useful for many languages and for many potential users, not only Ruby and YaST. B) Libstorage-ng is designed to be relatively low-level, not hiding details about how the different moving pieces (devices, filesystems, etc.) are connected and allowing to model all the possibilities that can happen in reality. That's perfectly fine. It makes libstorage-ng more versatile and powerful. But it has some implications. A consequence for (A): when taking API design decisions, if there are several ways of doing something and no way is universally better than the others[*], libstorage-ng always work in the way that is not standard in Ruby. That means libstorage-ng does not play nicely with the Ruby ecosystem, causing extra work for the Ruby developers just to keep using the tools chosen for YaST development and testing. For (B) it means libstorage-ng does not offer a direct answer to the kind of questions usually asked all around YaST (yast-packager, yast-bootloader, yast-country....). Although examples-based discussion has proved to lead to off-topic, I will try once again: A typical question from YaST to the storage layer: - For this given filesystem, which are the physical disks (whatever technology is used)? That question would be plain wrong from the libstorage-ng POV, because there is no such a direct relationship (not always) and therefore the user of the library is expected to know all the possible paths from a a filesystem to its disks and traverse all those paths doing the corresponding checks for empty and performing the downcasts in every step. In other words, there is no a_filesystem.all_disks But the user is expected to do this blk_dev = a_filesystem.blk_devices[0] if Storage.encryption?(blk_device) blk_device = Storage.to_encryption(blk_device).blk_device end return [Storage.to_disk(blk_dev)] if Storage.disk?(blk_dev) if Storage.partition?(blk_device) partition = Storage.to_partition(blk_device) if Storage.disk?(partition.partition_table.partitionable) return [Storage.to_disk(partition.partition_table.partitionable)] else # MD case end elsif Storage.lvm_lv?(blk_device) # The LVM case, which is double the size than the partition one end This is a simplified example don't taking into account he possibilities of multi-device filesystems or encryptions in other layers than the very first one (right below the filesystem). While adapting other modules to use the new libstorage directly we have found many examples of that gap between the abstraction level expected by YaST and the level of "clarity" about the internal structure enforced by libstorage-ng. So please refrain from discussing every single variable name in the example or providing an alternative with 4 fewer lines. That will not change the main point. :) So, as said at the beginning, libstorage-ng is perfect as it is, for the goal it is designed. That goal is not to be Ruby-compliant or to match the YaST use-case 100%. So we need an extra layer to walk that way. IMHO, opposing to the creation of that layer just to avoid the fact that some developers has to know and work with both layers is not reasonable. If you disagree, please provide counter-arguments to the provided arguments, instead of discussing the wording of the examples. ;-) Cheers. [*] As proved by the endless discussions focused on examples and counter-examples in which nobody convinces nobody else. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org