This is a "sticky wicket" and illustrates an important point I've been trying to make about repositories in general. IMO a "repository" is where the artifact is kept. Interfaces to the repository should therefore ALWAYS be links. That leaves a developer with only a few choices:
- Perform a lot of work developing code that provides and maintains permissions structures for places like Google Drive
- Rely on "publicly-shared" artifacts (now where's the file security?)
- Copy the artifact into a system already under the control of a roles and permissions architecture (I thought we wanted to get away from Moodle being the place where files were kept?).
Moodle has chosen to sidestep that work and copy the artifact into Moodle. I'm not blaming as I'm sure there are bigger fish to fry. It does cost quite a bit in usability though and maroons us in a place where we have to rely on a limited choice of export options. In the code for the Google repo it is indicated that the assignment of an export format for each type of document handled by the repo is "arbitrary", in fact the code at that location says:
// FIXME: We're making hard-coded choices about format here.
// If the repo api can support it, we could let the user
I don't much care if all the other repos have the infrastructure assembled to support "course-based" acls but I do care about Google, because we use Google Apps for Education and so do a whole lot of other schools so the payoff is high and the marriage between moodle and google seems "made in heaven".
I'm not just blowing smoke, our school (2,600 FTEs) has been using an honest-to-God Google Apps for Education repository that uses only links, provides for permissions based on course enrollment and gives a whole lot of other great whiz-bang, doo-hickey integration for the past year on 1.9. I've migrated it to 2.3 as a repo plugin. Quite frankly its a massive undertaking that has consumed a lot of man-hours. I'd be willing to share it with any school willing to assist in its enhancement and support.