This is a PR for #131.

@bwoebi: What do you think about limiting extension to allow for future extension in the specification?

Once we merge the separate virtual package for API, this isn't an issue.
Yes, it will require a major version for the Driver API, but not for the loop implementations themselves. (unless the implementations define a key with the same name but different value; in that case semver following implementations have to release a major version - but that's then specific for the applications implementing that particular loop.)

I do not see that future extension is exceedingly limited here.

But those implementations have to release a new major version. IMO they should add a separate method if they want to add more data, that will have a way lower chance of conflicting. Additionally, this would make the return of getInfo completely predictable.

Well, it's the choice of the implementations whether they choose to add more entries and incur the risk of having to sometime release a new major in the unlikely case of same key, different value.

The same way round you may argue that you could - without this restriction - rename keys in the Driver without requiring the implementations to release a new major (because they're allowed to retain the old key then).

The same way round you may argue that you could - without this restriction - rename keys in the Driver without requiring the implementations to release a new major (because they're allowed to retain the old key then).

No, you can't. This would break the API. I'm specifically talking about not breaking the consumer API, but still being able to break the SPI.

@trowski @rdlowrey @WyriHaximus How do you think about the extension?

Could anyone merge this?