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.

For example, a course worksite might have three roles: instructor, TA, and student. A hypothetical set of available permissions is described in this table:

These permissions are assigned to a site “XYZ” with a realm called ”/site/XYZ”.

Sakai also has special user realms that are used behind the scenes for any permission request. These special realms have two special roles, ”.anon” and ”.auth”. When the user is logged in, the permissions (functions) from the .auth role will be applied. When the user is anonymous (not logged in), the permissions from the .anon role will be applied. A logged in user will carry with him a personal user realm, a realm for his user type, and a realm for all users of any type.

Whenever a Sakai user attempts to visit a page or perform an action, deep in the code all the user realms are gathered together with the site realm for the entity under request. A check is performed: “Does the user have this lock in ANY of this collection of realms?” Remember that the user has at least one role in each of the realms. The way roles are used is not intuitive: if the user has role X in any of the collection of realms, then the permissions for the X role in all of the realms are applied.

An example is in order. Let's say a user is a student in some course site. The student role in that site does not have permission to upload new files. However, if the user has a user realm with “content.new” in the .auth role, then that permission is granted in the course site, or indeed any site.

Sakai has one more special realm that applies at all times: !site.helper This realm is useful to Sakai administrators who want to ensure that particular permissions are available to particular roles without regard to how any other realms are configured. For example, if you want to guarantee that users with the instructor role will have permission to create new announcements in their sites no matter how their particular site realms are configured, you would make sure !site.helper has an instructor role in it, and add “annc.new” to that role. Remember the rule: when permission is computed, if the user has the instructor role in any of the collection of realms, then the permissions for the instructor role in all of the realms are applied.

Sakai's permission rules allow for another scenario: the user realms and !site.helper do not normally have users added to them, but if an administrator does add users to a role in one of the special realms, those users have the permissions of that role wherever they go in Sakai. For example, if I create a maintain role in !site.helper and then add Bob as a member of that role within !site.helper, then Bob gets the maintain permissions in any project site he should care to visit. Whether this is a feature or a security problem is open to debate. What it boils down to is that !site.helper and the user realms must be handled with care.

Account Type

There is an optional field on every Sakai user record called “TYPE”. If this field has a value, Sakai will look for a user realm with an id of the form !user.template.<type> and that realm will be used for the permissions of its .auth role for every permissions lookup performed on behalf of that user.

Out of the box, Sakai defines a few user realms, but they're not used for much. A “guest” user cannot create a new worksite, while a “registered” user can.

1. There is plenty of stuff on here that might be junk, but I don’t know whether or not my computer needs it to run.
2. There is plenty of stuff that I know my computer does not need to run, but what if I need it someday?
3. Even if I did have a good method, sorting out the useful from the not useful would be a tedious, full-time chore.

That’s when it hit me: storage is cheap and networks are near-ubiquitous. Google’s Gmail service lets you keep all your messages for perpetuity, so why not extend this model to every file or document you’ve ever used? If your computer worked like this, your hard drive would only store the system files and documents that you need right now and push disused items into “suspended animation” in the cloud.

Computers work like this already on a small scale. If your CPU can’t find the data it wants in its level 2 cache, it goes and grabs it from main memory. Main memory can create the illusion that it is (for all intents and purposes) infinite by using space on the disk for infrequently-accessed data. You take a performance penalty when you have to hit the disk, but it’s worth it for the breathing room it gives your applications.

Now imagine that your high-performance hard drive is nothing more than a “level 5” cache. All the system files and documents that you are actively using will be immediately available, and if you want something you haven’t touched in 12 months, your computer will transparently pull down a compressed copy from the cloud. You would notice a lag, especially if the file is large, but in exchange you receive these benefits:

1. Your storage will be infinite, for all intents and purposes. Amazon S3 shows that this could be affordable.
2. You will never have to throw anything away unless you really, really want to. In the beginning, Gmail didn’t have a delete feature, and it freaked people out so they put it in.
3. You will never have to do housekeeping on your files. They key here is a first-rate index.
4. You will only upgrade your hard drive if you want better performance, not because you ran out of space.
5. You would have access to all your files from any device connected to the network.

Caching techniques are some of the purest of pure computer science, and way over my head, but they can be very sophisticated, including pre-emptive fetching. It should be possible for the “cloud cache” to appear to be able to read your mind.

If you want more evidence that this would work, consider this:

• Imagine that you have a huge video library, and could not imagine storing it in the cloud. Now go to http://hulu.com. Surprise, your video library is in the cloud. A download is nothing other than a local cache miss.
• Your browser already uses a small fraction of your hard drive for caching. We could just turn it up.
• For an example of an application of an always-full hard drive, look at Apple’s Time Machine. Once your backup drive is full, it quietly moves the oldest material off (in this case, to oblivion, but you get the idea).

If only I were pursuing a PhD, I could work on this. *chuckle* Someone else is going to have to do it.

I have been guilty of moving exclusively in Sakai circles, and it was great to break out into a broader cross-section of stakeholders in education technology. The IMS crowd is small but high-output; These folks know what is going on and are responsible for getting things done in their respective organizations. IMS has a large vendor representation, but this wasn’t a trade show at all. These are decision-makers coming together to promote standards for their mutual benefit. It’s funny to be an open-source guy at an event like this. “Oh, it’s a profit deal!”

IMS has put together a suite of documentation and testing tools to help developers produce and consume valid Common Cartridges, which should be a great help for smoothing and speeding adoption. Kevin Riley of IMS said that when they started testing Common Cartridges, the greatest source of errors was actually in misinterpretations of IMS Content Packages, which have been around for quite some time but have never had a similar validation system to ensure conformance to the spec.

When I started working on importing cartridges for Sakai, it was for Blackboard 5.5, and as there was no public specification, I only got it working by reverse-engineering whatever course cartridges I had on hand. It worked, but I have spent the subsequent four years responding to and patching for edge cases. I can only know about special cases as they pop up, and that has been one long headache. The great thing about having the Common Cartridge specification is that it will be possible to build an importer that will handle every allowable permutation of Common Cartridge from the get-go. And when we eventually (soon?) add Common Cartridge export capability to Sakai, the various validations will guarantee that our cartridges are proven correct before they ever go out the door.

The various publishers are eager to have one format to publish their content digitally. Pearson Education can already offer any of their cartridges in Common Cartridge format by request. Open University and Elsevier are also producing a ton of content this way.

The Common Cartridge mascot is a chicken. It took me until just this minute to get the joke: systems won’t support the format unless there are plenty of cartridges, and no one wants to produce cartridges if the systems don’t support it. Chicken and egg, duh! Well, the chicken has hatched, and the eggs are coming. It’s time to start making some omelets!

There was some talk that the Common Cartridge spec is too little too late, because the pace of change in technology has left it in the dust. I admit to being frustrated that it seems like it’s been “almost ready” for at least two years. It’s true that there have been plenty of exciting developments in technology that CC does not take into account (wikis, blogs, mashups, social networks), but the content it does support is not exactly obsolete: documents, images, videos, recordings, hyperlinks, discussion topics, assessments. After all, we still use books don’t we? There is still plenty of steam left in these “old-fashioned” media.

IMS has plans to incorporate tools as a content type for a future version of the spec. Hopefully that will allow Common Cartridges to tap into the cutting edge for many years to come.

Java DB is based on Apache Derby, which is an open source project that IBM spun out from a product called Cloudscape, which they acquired as part of the purchase of Informix, which itself had acquired Cloudscape as a two-year-old startup with around 50 employees in the go-go year of 1999.

Way back then, I was in the process of looking for my very first developer job (with no qualifications, I might add). A few projects later, and my team had selected Cloudscape as our best bet for a cross platform client-server system to teach struggling kids how to read. This was back when you had to shell out $50k to use the software. In an act of surprising optimism, they put me on the project as the database lead! The first thing I did was buy a shelf-load of books about databases. I was so green I wrote my own connection pool! Java development on Mac OS classic was hell, but Cloudscape blew my mind because you could use objects as a column type, and invoke methods on them from inside a SQL statement. A glance at the docs suggests it doesn’t work this way anymore, though they do have an XML column type.

It’s good to know that some good software can survive the corporate churn-and-burn. Who knows, maybe I’ll use Java DB née Derby née Cloudscape again in the near future.

image courtesy of the Wayback Machine

Key points for me:

• SOA aims to tackle the problem of too much cost and redundancy in enterprise IT
• If you develop a capability, it should be reusable across your applications
• You want to avoid building monolithic applications
• SOA is something you do not something you buy
• Having an Enterprise Service Bus does not mean you have SOA
• SOA requires an organizational lifestyle change; You have to apply the principles across all the projects in the organization
• SOA is a long-term proposition, on the order of 10 or 20 years

Those last two sort-of make my eyes bug out. Do you know anyone in technology that makes 20-year plans? My feeling is that our organizational hierarchies simply prohibit cross-cutting changes like this in the enterprise. Either the CEO is demanding this from every division, or it won’t go forward.

I do think the principles are interesting. IT is such a young industry that we are learning for the first time what it looks like to have 40 years of cruft in your infrastructure. Certainly anything that begins to scrape away the barnacles should be good for the organization.

Here’s a small series of humorous episodes related to recent Blackboard and Open Source Learning Management Systems. The mashups are made with snippets of classic Hindi Bollywood films, overlaid with user created subtitles, from a fun online tool called BombayTV from Grapheine. The role of Blackboardwala is played by none other than Amitabh Bacchan, of course.

http://metamedia.typepad.com/metamedia/2008/04/the-adventures.html

http://wordpress.org/development/2008/03/wordpress-25-rc2/

They’ve been working with the web geniuses at Happy Cog and the results look awesome.

WordPress is seriously firing on all cylinders. It’s a Good Thing.

It’s also a great learning tool, since you have a working tool in less than two minutes and you can start playing around with modifications.

As before, new videos are posted here: http://aeroplanesoftware.com/sakai-training-videos

Here is your link.