Toward Real Extensibility in Sakai

0zach • 17th Jul 2009 • Conferences, For Developers, Sakai, Technologies

At the Sakai conference in Boston, I sat on a great panel with other developers and discussed what it would really take to make Sakai the platform for innovation that we want it to be. The audience was active in the conversation as well. We heard a lot of analogies to other systems. Here are a few ideas I picked up from the session.

The platform should allow contributions with very low startup costs or friction. The startup cost for contributing code to Sakai right now is huge. Even if you figure out how to setup your development environment, the project directory structure, the pom.xml file, the web.xml file, your API, your component pack, your tool registration file, and how to access Sakai components, you still have to have direct administrative access to the instance(s) of Tomcat where Sakai runs so you can load the app. The ideal would be that a part-time contributor could publish some code, as little as a single text file, and any Sakai site maintainer could try it out. Someone in the audience whose name I didn’t catch said we need “the Hypercard of Sakai.” This should be technically possible. The trick is to figure out the runtime environment: either it runs in the JVM with Sakai and must be scrupulously sandboxed, or it runs anywhere on the web and publishes a UI for Sakai to consume.

We can learn a lot from the extension hooks provided in other open source projects. jQuery is a great example. A jQuery plugin is just a single JavaScript file that loads with the main jQuery library and “sprinkles on” new functions that are then available to the hosting page. A jQuery plugin can be loaded from anywhere on the web with a single URL.

One of my new favorite frameworks is Grails. A Grails application is a standard Java webapp, so in that sense you still have to get it over the “wall” of your data center to run it, but the mechanism for adding features to the framework for other developers to use is ingenious: a Grails plugin has the exact same structure as a Grails application. You install it over the network with a single command, and it is simply overlaid at runtime onto your application. To contribute a plugin, you sign up for credentials to their Subversion repository, and then commit anything you like to your private space. It’s just like contrib in the Sakai community, with the important difference that whatever you contribute is automatically in the directory, and is discoverable and usable by any Grails user with a single command.

We could also learn a lot from the Facebook application platform. Once again, the barriers are low: you register as a Facebook developer and they send you an API key. When you develop a Facebook app, it runs on your own servers, using whatever technology stack you choose, and Facebook provides the APIs to access their data and the hooks to surface your app within their system. I think this could be a great model for extending Sakai, though I believe we will still want to provide the option to host contributed code on our servers.

Dr. Chuck’s work with learning tools interoperability takes the Facebook idea further, allowing you to embed applications anywhere on the web, not just inside some “official” boundary.

Finally, Sakai’s next generation kernel will be build on Apache Sling, which will enable applications with (optionally) no server-side code whatsoever; You can build an app entirely on the client, and use Sling’s RESTful content APIs to interact with institutional data.

The future is bright, but as I said in the panel discussion, I think it’s too early to give up on Sakai 2.x. There are a number of technical pathways toward real extensibility in the systems we use today.