Make Runtime Services Plugin-able

[cpennington]

Handwavey Sketch:

1. Use stevadore to register/lookup installed plugin implementations (plugins for the 'i18n' service would be registered under the entry_point key 'xblock.service.i18n', and would be named for their function ['null', 'django', etc])
2. XBlock runtime should look for services in the following order:
   1. Explicitly provided in the services kwarg
   2. Enabled entry_point plugins in the provided services configuration dictionary, configured by that same dictionary
   3. Default plugins registered with stevadore (maybe?)

[cpennington]

@pmitros: Does that look like about what we'd talked about?

[pmitros]

Sounds right. I'd also consider some mention of default plug-ins which come with the XBlock repo as lowest on the totem pole.

[pmitros]

The stevedore thing is actually pretty important -- being able to pip install, as an XBlock, with no additional config work.

[cpennington]

I guess my thought was just that the default services from XBlock would be provided via the same plugin mechanism.

[pmitros]

Sounds right.

[nedbat]

Can you fill me in on the conversation? Services are provided by runtimes. Will we require that any runtime use stevedore to extend the set of services? What API will the plugins use to connect to the rest of the runtime, and how do different runtimes support the same API? This seems like adding another level of indirection. What problem is it solving?

[pmitros]

@nedbat We need a file system service in XBlocks for a few things I'm doing. We'll need more services in the future. We'd like to, as much as possible, build those services once, and use them in xblock-sdk, edx-platform, and any other runtimes that may appear in the future. Many of the services may also be desired in other parts of the platform.

Runtimes connect xblocks to services, but if all the services have to be independently created by every runtime, and any time a new service is added, the runtime has to be patched, that's a lot of work, overhead, and replication.

[pmitros]

@cpennington One more point: I'll bring back an issue we tabled, just so we have it here:

• One of us suggested that the runtime be able to have multiple implementations of the same service, and an XBlock be able to request a preferred implementation, if available.
• The other one suggested that the XBlock should not be able to request a specific implementation, but rather that the runtime should pick the implementation.

We tabled this and did not get into a technical discussion as to use-cases and arguments both ways, so either of us could be right/wrong, but I'd like to leave this as an issue to discuss when and if we build this out.

(edit: removed names who suggested which version :) )