Anthony Liguori <anth...@codemonkey.ws> writes: > On 06/01/2012 07:43 PM, Markus Armbruster wrote: >> Anthony Liguori<anth...@codemonkey.ws> 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. [...]
