Interfaces

[Mark Shuttleworth]

On 04/03/16 06:13, Gustavo Niemeyer wrote:
> There was so much discussion around these terms that it'll probably be
> quite difficult to change them now.

On the contrary, we're in the very mode of deciding for the long term,
and until we GA, we are willing to continue trying to improve language.

> Just as some insight into aspects that were considered:
>
> - The term "consumes" implies depletion, which is unsound for some of the
> interfaces
>
> - Both consumers and providers must "implement" their end of the interface
> for it to work, so "implements" meaning one end would create terminology
> conflicts
>
> - If we implement and consume interfaces, we don't have terms to refer to
> the two endpoints in a tangible way; what is today "the plug" becomes "the
> consuming endpoint of the interface" ("the consumer" won't cut, because
> that's the snap itself)
>
> - We need terms for the connection aspect; we might still "connect" the
> consumer to the implementer, but the analogy is poor compared to connecting
> plugs to slots.
>
> - Plugs and slots are both short and have the same number of letters.
>
> ... and so on.
>

I think the stronger argument against provides/consumes is that they are
adjectives, when we actually need a noun. I understand Sergio's
appreciation for the explicit provide/consume language, but the problem
is that we need to refer to the thing as a THING. Try to imagine
describing the snap itself. "This snap has 7 THINGS it provides that
implement three different interfaces". That's weird. The reality is,
each of the IMPLEMENTATIONS of an interface is a thing with a name that
can be connected/assigned/passed to another snap. The word we want
really must be a noun, because otherwise there is no nice way to talk
about them.

And we really want two, matched nouns, like plug-slot or yin-yang or
tap-sprinkler or male-female or key-keyhole, so that it's clear when we
refer to a thing whether it is a provider or a consumer.

Mark