Mailinglist Archive: yast-devel (87 mails)

< Previous Next >
Re: [yast-devel] Feedback needed! Hack Week project to re-define storage-ng API
On 02/24/2017 02:43 AM, Ancor Gonzalez Sosa wrote:
On 02/23/2017 09:31 PM, Arvin Schnell wrote:
On Thu, Feb 23, 2017 at 05:45:48PM +0100, Ancor Gonzalez Sosa wrote:

My Hack Week project is in that state in which all the important parts
work and now it's time to decide if it's worth investing a couple of
extra days to finish it all the way down.

Since the ultimate goal is to change how YaST interacts with storage-ng,
I would need the opinion of as many YaST developers as possible.

So please, please, please, take a look to this and give your opinion.
https://github.com/yast/yast-storage-ng/pull/169

So let's me try to redirect this thread before it becomes a re-edition
of the exceptions vs nil one. Don't let one or two single controversial
points ruin the full discussion[*].

My proposal is to avoid exposing the libstorage API all along YaST
because I consider that exposure to be negative in the long run. Let's
focus only in the less controversial points of that reasoning.

- Constantly performing downcasts in the Ruby code. I believe we can
agree that's the less Rubyist thing ever.

- Exposing (SWIG/C++) artifacts, like strictly-typed vectors instead of
Ruby-style collections, all along YaST.

- Quite hard to add YaST-oriented logic on top. At this point there is
already quite some extra logic we have needed to add, using/inventing
some workarounds to make that possible (refinements, monkey-patching and
more).

- Workarounds needed when using standard Ruby tools like RSpec, caused
by the fact that we don't do things in the standard Ruby way. I'm not
discussing whether duck-typing is better than strict type-checking or
whether enums and exceptions are better mechanisms than classes and nil.
I'm just saying than doing things in a different way that the whole Ruby
ecosystem is constantly causing extra work on our side[*].

- Mixing bytes (Fixnum) with Y2Storage::DiskSize objects.

The most important question is - do you prefer the proposed approach and
API* or do you prefer to continue accessing directly to libstorage-ng
from YaST?

For me it will make programming in Ruby more difficult since I
have to know two APIs (already mentioned in doc/design-decisions.md).

That's a valid point that affects those who know/develop the libstorage
API and, in addition, has to develop Ruby parts of YaST (i.e. the S
subteam).

So far, this is the only clear argument raised against adding a Ruby
layer between libstorage-ng-ruby and the rest of YaST.

The rest of the thread has "focused" on discussing one or two particular
points of the initially proposed API[*]. So I want to leave those
controversial points out of the discussion and focus again in the main
question.

THE_ULTIMATE_QUESTION <<

Is it worth introducing that extra layer in order to fix the
above-mentioned problems (that we have been suffering for some time) at
the cost of forcing the S subteam members to live with two versions of
the API in their heads?

EOF_ULTIMATE_QUESTION

Again, this is a question for the whole YaST team. So please, don't get
scared by the amount of mails in the thread discussing small API design
details and give your opinion on the main topic.

Cheers.

[*] All those discussions (nil vs exceptions, enums vs classes) has
already proved to be useless in the past regarding the goal of reaching
consensus, so we should stop them.
But IMHO they have proved something. That there are two clearly defined
sides with two clearly defined opinions: developers with a Ruby
background vs developers with a C++ background. We will never reach a
full agreement on which approaches are better for each controversial
point. But using the Ruby approach in the Ruby code and the C++ approach
in the C++ one looks to me like the only way to avoid discussing the
same over and over.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups