Mailinglist Archive: yast-devel (211 mails)

< Previous Next >
Re: [yast-devel] Some notes about new storage API
On Tue, Oct 13, 2015 at 03:19:45PM +0200, Josef Reidinger wrote:
On Tue, 13 Oct 2015 14:54:40 +0200
Arvin Schnell <aschnell@xxxxxxxx> wrote:

On Tue, Oct 13, 2015 at 01:05:16PM +0200, Josef Reidinger wrote:
On Tue, 13 Oct 2015 11:29:44 +0200
Arvin Schnell <aschnell@xxxxxxxx> wrote:

On Tue, Oct 13, 2015 at 10:14:03AM +0200, Josef Reidinger wrote:

I'll do more experiments with this as soon as the prototype is
easily installable. But looks pretty clear that it would be
fairly easy to fix the un-rubism by adding the corresponding
methods in the Ruby side in case we decide we are so purist
that we cannot live with the current API. :-) So nothing to
fix in the libstorage (C++) side.

I agree, that it make sense to have some helpers to have ruby
bindings more "ruby".

Just remember that those need documentation and test cases.

a) Is device_graph always an object representing the whole

The devicegraph always represents the whole graph.

Well, in general I do not like this API before and I also do not
like it now :)
It is not object oriented and whats more device_graph is god
like object.

Please elaborate this. What do you mean by God like object? A
object that holds all storage objects?

Yes, if you have object that hold everything it is not graph, but
flat structure.

Sure it's a graph, see, esp. "a
graph is a [...] pair G = (V, E) comprising a set V of
vertices [...] together with a set E of edges [...]".

OK, to be precise graph of objects, not just data.

But the device graph does hold objects and all the storage data
is in that objects. Just look at Devicegraph.h and you can see
that it is a small class.

I consider a single search function, as was proposed, as too
powerful (among other problems already explained).

Question is if for user is easier to learn and understand powerful
method or powerful object, that have bunch of methods.

The design has a many objects with few functions.

That is something different. Now you have one object that holds it.
so it is like

device_graph -> A, B, C, D, E

That is not a graph but just a list of nodes without edges.

I just want to demonstrate why it is god object and flat desing.
device_graph point to everything. So it is god or big brother :)

No, it is not. The device graph does not directly contain all
storage data.

Difference is who knows about connection. If graph knows about
connections or nodes.

Suppose you have a system with ten empty disks and you represent
those not in a graph or list. How can you iterate over all disks?

In the current prototype the functions can work on all graphs,
whether it's the "system", the "staging" or "my ideas" graph.

And is it reusable code? Now all code depends heavily on device_graph.
So if I want reuse some class elsewhere I need big god object like
device_graph. If it is used by smaller classes I know that for
reusability I need implement few abstract classes or in ruby case have
objects that responds to given set of methods.

Many functions simply cannot work without more knowledge of the
graph. E.g. partition functions need the partition table type,
logical volume functions need the name of the volume group, etc.

So the objects have a backreference to the graph on

Otherwise you would indeed end up with objects that just hold the
storage data and a bunch of floating functions taking as the
first two arguments the device graph and object. That sounds like
a horrible interface.

If I am interested what e.g. device_graph provide me, I can do
device_graph.methods which in case passing device_graph everywhere
do not should interesting stuff. Also methods is not documented in
it and lives elsewhere.

Sorry, I don't understand that.

My point is that class in object design is encapsulated data and
ability it provides, so for usage you check methods of class. But
device_graph have a lot of methods that lives in different place.

Do you look at Array when you want to know that you can do with
the Person stored in Array<Person>?

The graph is just a container.

If I get you right you want to replace documentation by

In general no. introspection is to get ability of object. Documentation
is to get details of abilities. Introspection is useful when you want
extendable interface.

Then I don't understand you.

And thats the point. I think it is wrong if all data is hold by
device_graph. It is not clear for me how extension can extend data if
it is all hold by one class.

It is not all in Devicegraph. Look at the class. Look at
Filesystem class. Where is the filesystem label and UUID?

And BTW how Storage::Filesystem class holds data to find
shows that it use data from device graph, which holds all data.

No, it uses Devicegraph as a container but the mountpoint is in

I think in general conclusion for me is that I do not like data centric
api with device_graph and we do not agreed on that, so I am interested
also in others opinion.

The design is not data centric.

The general conclusion for me is that this thread gives no new
insight and unless really new ideas come up I will not comment

ciao Arvin

Arvin Schnell, <aschnell@xxxxxxxx>
Senior Software Engineer, Research & Development
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >