This was discussed today during the meeting and these were the points where developers did not reach consensus yet:
- Requiring MOOCH registration. On contrary to the proposal above, David and Eloy are not happy with interfering hubs into this.
- Providing the list of currently installed plugins during the request. David and Tim objected that there is no need to send the list of currently installed plugins. Just the version information is enough and the response would contain the list of all available plugins for the given version. The processing of the list would happen at the client side (eg it would display just available updates or the list of available plugins to download in the future - without the need to change API of the service!). Eloy and David think that sending the info about installed plugins should happen during the registration only.
Note that we don't have much time for 2.3 development. On the other hand, we don't want to change the API of the service in 6 months again. From my point of view, this is the conceptual question to answer: Should the access to the information about available plugins be public/open (for all clients including non-Moodle apps), or should it be only for Moodle sites, or should it be only for Moodle sites registered at a hub, or should it be only for those registered at MOOCH? Answering this determines whether we can or can't send the list of currently installed plugins.
With regards to my +1 towards heavy-weight REST WS above - my reasoning was pretty selfish. I know we will need this WS for yet another Plugins related project (AMOS/Plugins integration) so this was a nice opportunity to learn something about WS. However, if we decide for the open one-way communication channel (ie Plugins just serving the info about all available plugins without collecting stats), we can make it as a light-weight REST service without auth and friends.
Writing this, I can see sort of compromise solution. Let us imagine API that works both with and without additional query params. So the plain query (GET available plugins) would just return all plugins registered in the Plugins. However, the caller might specify target Moodle version/build/branch and then only filtered plugins would be returned. Similarly, the caller might specify the frankenstyle names of plugins it is interested in and the filtering would happen again.
Into Moodle 2.3, we would implement the client that queries the Plugins and provides the target version and build and currently installed plugins. So we could get some rough estimations of plugins usage world-wide even without matching them with registered sites.
p.s. nobody came with a solution of what the source of Moodle version itself will be. That is, where will we read the information about available Moodle core update.