A successful implementation would be pluggable in that it can be added to an existing Sakai installation without recompiling other modules (even for configuration). With this as a design goal, there should be at least one new top-level module to contain any base/reference handlers, and the selection/configuration mechanism should be external to the module.
Thanks for the fix @buckett. I think it for sure makes sense to have these lazy but I'd consider this still incomplete because if you have the configuration incorrect it can be hard to debug which settings are missing or wrong if you're using this. I'd agree this init method should still have additional error checking. I wonder if we have more beans like this out there.that really are only used in special cases and could be avoided starting to speed up start times & save memory.
Noah Botimer July 1, 2015 at 9:46 PM
Licensing and tests addressed. See pull request for specific discussion.
Noah Botimer June 13, 2015 at 3:48 PM
This is still in progress pending some licensing info being added to the pull request, but otherwise finished.
The FileSystemHandler introduced in https://sakaiproject.atlassian.net/browse/KNL-1268#icft=KNL-1268 makes way for cloud-based handlers for content files. The first two obvious candidates are OpenStack Swift and AWS S3.
A successful implementation would be pluggable in that it can be added to an existing Sakai installation without recompiling other modules (even for configuration). With this as a design goal, there should be at least one new top-level module to contain any base/reference handlers, and the selection/configuration mechanism should be external to the module.