The goal of this project is to write a proof of concept of a new philosophy for yast2-storage-ng. Instead of just extending the API offered by libstorage-ng, the idea is wrap libstorage-ng so the Ruby code using yast2-storage-ng does not have direct visibility (unless explicitly desired) on the libstorage-ng classes and methods.
If you don't know what all that means, keep reading.
The YaST team is rewriting the storage stack (the part that manages disks, partitions, filesystems and so on). In the current implementation the low-level operations (partitioning and so on) are performed by a C++ library called libstorage. On top of that, yast2-storage provides an API for all the other YaST components and modules.
In the new implementation that should debut in SLE13, libstorage-ng already offers a higher level object oriented API with Ruby bindings (generated using SWIG). Although yast2-storage-ng is still there offering convenience classes and methods, now other YaST components directly use the classes provided by libstorage-ng to inspect the system and so on. So, contrary to the current implementation, yast2-storage-ng does not wrap libstorage-ng, but complements it by offering additional classes and refinements on top of the classes provided by libstorage-ng.
Now that libstorage-ng and yast2-storage-ng are quite feature-complete (although still far from the current versions) and used in several other YaST components, the direct use of libstorage-ng is starting to show some annoyances.
- Sometimes, the strict type-checking imposed by SWIG forces the Ruby code using the library to look clumsy (explicit type casting, a lot of calls to
#to_ain almost every collection coming from libstorage-ng, etc.).
- The structure of libstorage-ng is very flexible and, by design, it never hides that to the user of the API. Offering a method like
a_filesystem.diskwould go against the philosophy of the library. The user of the library is expected to do something like
a_filesystem.blk_devices.partition_table.partionable. That adds clarity about the real libstorage-ng structure, but does not ease the common case.
- The C++ take on object orientation sometimes differs from the Ruby one. We have discussed for very long time and in many threads about several aspects of the libstorage-ng API without reaching a clear consensus between the two "sides" of the team - the developers with a solid background in C++ vs the Ruby purists.
Fixing those problems by adding many refinements feels wrong (refinements are still second-class citizens in the Ruby world). On the other hand, YaST does not need access to every single class provided by libstorage-ng, at least not in a regular basis.
So let's see go back to the wrapping approach and see what happens. I already tried in the past and SWIG was too much in the way. But now I have new ideas.
Looking for mad skills in:
yast ruby c++
Activity Show All
This pull request shows some working code and explains how the new layer works (or would work when finished). Used as base for discussing the concept with the whole YaST team. Despite the length of the thread in the yast-devel mailing list, the proposal was well accepted. 7 out of the 8 YaST developers who expressed their opinion (in the mailing list or the PR) like the new layer and think it's the way to go.
I spent the last day of Hack Week analyzing how the current query interface is used from other YaST modules and how to adapt that query interface to the new layer. The conclusion is that we just need to add some methods to the new layer and then we can even drop the current query interface.
So we just need to allocate some time to finish this.