Thomas Adamcik

Mhm, that is the major downside for the use case you have in mind. For the log levels things it maps a lot nicer. So doing some like the following...

Added https://docs.mopidy.com/en/develop/api/config/#mopidy.config.schemas.MapConfigSchema for a colored logging change just now, not that this solves the question of how to use this in an extension and if it's a sane solution for...

If I remember right we made `get_config_schema` a return a single schema on purpose to limit the possible namespace pollution extensions might do, if that was a good call or...

As I just said on IRC I've made it as far as: ``` class Dict(List): def deserialize(self, value): values = super(Dict, self).deserialize(value) result = {} for v in values: k,...

As part of https://github.com/mopidy/mopidy/issues/310 I want to switch to having an options model and a add core API for getting all off them at once. And for events we are...

My only real concern with this is that the current call signature for `options_changed` does not allow us to send extra data, and that would be a breaking change for...

I'm leaning slightly towards a `TracklistOptions` model and adding a `Boolean` field type. Reasoning being we then have type checking built in.

I've thought about this at times, and the likely solution is to allow the classes implemented by extensions to be config listeners. Upon config changes all the listeners would be...

By core config service I mean something new inside 'mopidy.core.*' which also exposes configs over the WS.

Initial thoughts: - This looks really usefull - Should it be tied to devices or could / should this be just a generic discovery service? - What other use cases...