Sakai Development Diary - Prelude

My next major job will be to write an extension to the Sakai research environment software which enables the deposit of material from Sakai to some SWORD2 compliant repository. (SWORD2 is a protocol for the deposit of digital materials into repositories, so this is a reasonably sensible project to undertake.) This work is funded by JISC through the Research360 project based at the University of Bath, but this is a personal blog and the content does not represent the opinions of either JISC or the University of Bath, and any mistakes are my own.

My Sakai background is negligible, so I will be starting from scratch. I have had a look round the Sakai website, and had a chat to some people who know the system better than I do, and have not been left much wiser than when I started. This is really the reason behind this diary: it does not look easy to pick up the information that is needed to start developing for Sakai, and documenting how I went about it and what worked should therefore be helpful to the Sakai community. With that in mind, I will try not to be too critical, curbing my natural inclination to sarcasm.

First Impressions


The website for Sakai is very corporate-looking for an open source project. Clearly, that is a good thing in many ways - it certainly convinces the reader that the tool is one which has been thought through and which has had a lot of work put into it. The emphasis on the front page is on the community, which is one of the main concerns of open source software projects. So it looks healthy - at least from the point of view of a potential installer.

But the community of researchers who use, or who might be persuaded to use, Sakai are not the only people who will be going to the website. An open source project is likely to attract people who are interested in contribution, as I am. What information does the website hold for developers?

The front page itself tells me that Sakai is not just one tool, but two: the CLE (Community Learning Environment) and the OAE (Open Academic Environment); from the names, it is clear that the latter is what interests me. There is a big difference in what is available for the CLE and the newer OAE; it is possible to try out a hosted installation of the CLE, but not of the OAE. At the moment, I don't have a development environment suitable for setting up a development installation of Sakai, so I tried out the hosted CLE - an interesting experience. The hosted environment comes courtesy of a choice of commercial affiliates to the Sakai project; I chose Unicon, mainly because it is the first in the list. (The other link of interest on the Sakai home page, Getting Started, which leads to a page from which I chose Technical Contributor information, ends up suggesting that trying a hosted version of the CLE is the first step.)


Clearly, Unicon have been generous to support such a free service, so that is to be applauded - but I still felt there were some issues with the trial system, apart from it being the less relevant of the two Sakai tools. At the Unicon site, the potential user needs to create an account. The form for this has quite a lot of required information (at least, I assumed that fields with a red star next to them were required, as the sign up page doesn't actually say so), including some which, as a consultant rather than an academic, were a little difficult to choose how to complete - I don't have an academic department, for example. But I'm only doing this to have a chance to play around on the system for a short while, just to get a feel for the sort of things that Sakai can do. What is more irritating is to receive a confirmation email which contains my password in clear text. (See here for why this is a bad thing for security.) However, the account is temporary, only working for 90 days, so it is not a disaster, even if it is off-putting for a software developer - does this mean that Sakai is going to store user passwords in unencrypted form?


Trying the software without clear goals in mind is less productive than it might be. The main thing about it is that it does leave me with a positive impression of the ease of use and potential for versatility of the software.


What's the second step? Joining the appropriate Sakai mailing list. The only information that is given on the Sakai website is the list of the 50+ mailing lists, with a minimal description of each - the longest of them is just 12 words. I decided to join announcements, the programmers' cafe (I'm not quite sure whether this is a mailing list for informal discussion between developers, or about a specific part of Sakai called the Programmers' Cafe - but I can always unsubscribe later), and oae-dev, and sakai-dev.


The Technical Contributor page now suggests setting up a jira (bug tracker) account. This done, I have a quick look round, and start to find the kind of information I need to get started. That is, I now know that there is a Sakai OAE Widget Library (for example): this sounds relevant, but all I can see here are bug reports - the jira project listing does not give a website, as it does for the majority of projects. Now I know that it exists, I should be able to find out more. It's a bit annoying to have to go to everyclick (the search engine I am currently using, so that every search I do donates to charity) to find the website for the project. A bookmark to go back to later, though I do have time to discover that there isn't single sign on between any of the things I have registered for today, and I'll need a new userid and password to use the library website. If  I had not used jira before, I might have found it quite hard to actually discover the projects, as the tab to click on is not particularly obtrusive.


From this point, the Technical Contributor page starts to get quite CLE specific, so I think that my next task - once I have a development server - will be to download and install the OAE.


SWORD is a smaller scale project, and this is reflected in a far plainer website (and in the geekiness of their logo!). But then, I am a developer, and not so interested in being sold the product as in finding out how to use it. What do I want to know?


I have some idea of what SWORD is already, but not much about the differences between version 1 and version 2. The site has prominent links to the specifications for both versions of the protocol, and I bookmark the version 2 definition for later perusal - it's going to be extremely important when I start working on it, but is not light reading, and I'll probably forget most of the important details between now and when I actually need to know them. Following a link to SWORD2 implementations takes me to a much more immediately important list. There are client toolkits which would help me write my Sakai extension in Java, Ruby, python or PHP, and a list of servers known to support version 2 of the protocol, which will be important when I come to testing it out. I have written code in all four languages, but I have yet to find out what restrictions Sakai will place on what I can use. Not only that, but the different client toolkits all have decent looking documentation. I feel that finding this out is actually my biggest achievement so far: well done Stuart Lewis, the author of the page!