Re: [Qemu-devel] Can we improve virtio data structures with QOM?

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> On 06/01/2012 07:43 PM, Markus Armbruster wrote:
>> Anthony Liguori<address@hidden>  writes:
>
>>
>> No, a user should use what solves his problem nicely.
>>
>> Most of the time, the problem is simple.  I quite agree we should
>> provide simple ways to solve the known simple problems.
>>
>> Occasionally, you run into a non-simple problem, and then you'll really
>> appreciate a discoverable bridge from the simple way to the general way.
>> You'll also appreciate when the general way still satisfies basic
>> usability criteria.
>>
>> A mandatory parameter that must have the one right value, or else things
>> break, doesn't satisfy.
>>
>> "Experts/tools only" is no excuse for shoddy interfaces.
>
> Links are unidirectional.  A pair of links provides a bidirectional
> interface. Today we don't have a mechanism to establish a pair of
> links.  It's unclear to me what such an interface ought to look like.
>
> I'm not fundamentally opposed to such an interface, but this would be
> syntactic sugar IMHO.
>
> And I strongly disagree with your statements above.  It's lazy
> interface design to have a "low level interface" and tell users that
> if they can't do what they want with our high level interface, they
> must drill down to the low level.

Sure, except it's not what I proposed.

There needs to be a simple way to solve simple problems.

There needs to be a general way, so that even non-simple problems can be
solved.

There should be a discoverable bridge from the simple way to the general
way.  Adding optional arguments to the simple way is such a bridge.
Sometimes your simple way can't do that, and then you need to think
about alternatives.

>> -drive isn't such a good example for "simple"; it's a bloody mess, in my
>> opinion.
>>
>>> Heck, I still think we should do -vda foo.img.
>
> See above.

I don't mind -vda as additional shorthand notation.  Would be bad if it
was the only simple way, though.

>>> Most likely they will.  But I don't think users should be setting any
>>> links in the first place.
>>
>> Real tools aren't built around ideas on what users shouldn't be doing
>> with them.
>
> I disagree.  That's what UX is all about.  But really, let's step back
> before we run off a cliff debating abstract notions.
>
> QOM's is an API.  It's not meant for casual users to do anything with.
> It should be a *usable* API and APIs that are hard to misuse are
> definitely a Good Thing.
>
> I tried very hard to add features to QOM to make it difficult to miss
> set properties which is why everything is aggressively typed.  I'm
> violently in favor of making it a safer interface.

If a pair of links must point back to each other for things to work,
then we have a safety issue and a design issue:

Safety: do not permit settings that cannot work (unless detecting the
misuse is impractical).

Design: do not make me specify mandatory parameters that can take only
one value (unless the redundancy serves a worthwhile purpose).

Both apply to API just as much as to UX.

> But let's not conflate good API design with UX.  They are very
> different things. And yes, this is why QOM only really supports QMP
> today as an interface.
[...]