Add "core extensions" support?

[adamcik]

#1085 is part of the context for this. Idea is to have an extension point for providing shared functionality to front-ends. Examples of this would be the sleeptimer in the PR mentioned and possible the history API.

Essentially this would be trying to limit core to providing the tracklist, playback and coordinating access to backends. Things that fall outside of this are candidates for becoming core extensions currently.

The functionality exposed should be added to https://github.com/mopidy/mopidy/blob/develop/mopidy/http/handlers.py#L39 under a core.extensions. Open questions are currently how to do listeners for this, naming of things and how to expose this on the python side of it all.

[kingosticks]

Does exposing settings fall under this? #502

[adamcik]

@liamw9534 this is probably more or less the same as the service stuff you wanted to add?

[liamw9534]

Yes, it might be worth looking at what I did first. It allows, selectively through decorators, any service extension class' methods to be exported over HTTP API. Each extension is then listed as a service with a unique service name and each service has a getter and setter function for its properties.

It is somewhat more all encompassing than merely allowing settings to be exposed, since the extension class can export any or all of its methods for remote calling.

Also note that no specific implementation of property setting/getting is assumed either.

[jcass77]

+1!

[teq0]

@liamw9534 are you referring to this - liamw9534/mopidy#2? What ever happened to it? It looks like a great idea.

[liamw9534]

It still exists on an old branch which I worked on about 9 months ago. I would very much like to resurrect it but struggle for time at present owing to some personal commitments.

I have the whole of this Saturday free to myself so maybe I will spend some time on this!

[teq0]

I'm having trouble reading the general sentiment here as to whether this is a viable alternative to adding a plugin mechanism to the core.

I'm biased because I had a particular use case and I think this would certainly work for my case, but it seems to me that allowing extensions to easily surface client-side APIs through decoration is a very clean way to enable extensions to appear to be part of core without the need to really plug directly into the core.

[adamcik]

I'm for the idea, I just don't think we sat down and decided the details of how to expose core extensions.

[paulogr]

This is very old.

Is there a current way to extend the core lib? I want to add a custom event to listen on my frontend extension but got this error when trying to send a custom event.

curl -X POST -H Content-Type:application/json -d '{
  "method": "instore.check_new_playlist",
  "jsonrpc": "2.0",
  "params": {},
  "id": 1
}' http://localhost:6680/mopidy/rpc

{"jsonrpc": "2.0", "id": 1, "error": {"message": "Method not found", "code": -32601, "data": "No object found at \"instore\""}}

Is there any workaround? How to setup a custom event for my frontend?

Thank you!