Mailinglist Archive: yast-devel (25 mails)

< Previous Next >
Re: [yast-devel] The long way to a new libstorage: target map wrapper

Hi Stefan,

thanks for bringing this up.

The main problem I see with your approach is that we end up with
that wrapper at the end of the day. So we would have libstorage
<-> wrapper <-> ruby. Depending on the complexety of the wrapper
it means more documentation, more difficult debugging and more
work for new features.

I my proof of concept redesign there is also a wrapper but at a
different level: It provides the C++ interface of the existing
libstorage for the redesign libstorage. That way the ruby code
can stay as it is while switching the underlying library and then
the ruby code can be converted piece by piece. In the end the
wrapper (and the target map) will be obsolete.

In the proof of concept I have already show that such a wrapper
is possible (in Febuary it was able to install the most simple
system) and that the interface of the new libstorage can be used
at the same time from ruby. I admit that since the data structure
of the redesign libstorage is very different from the old one the
interface wrapper is not simple but tricky and implementing every
corner-case will be difficult. So including the wrapper in a
maintained release it not what I recommend.


To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation