OSP 2.6 Demo If you were unable to attend today's OSP Demo, there is an audio recording of the Adobe Connect session available. The demo was presented by Sean Keesler and Janice A. Smith, both of Three Canoes, and provided an overview of the changes and enhancements to the portfolio tools in Sakai 2.6. If you're not familiar with the Sakai portfolio tools, you will still find value in the presentation's demonstration of various portfolio capabilities, as well as some of the questions that were asked and answered. Look for additional materials and links that Sean and Janice share post-presentation on the sign-up page for the event, including the slides from the presentation.

RINET 2009

Earlier this week I spent a couple enjoyable days in Providence, Rhode Island at the RINET 2009 Sakai Conference. Hosted by the Rhode Island Network for Educational Technology (RINET), in association with the Sakai Foundation, this conference provided an opportunity for regional Sakai users to get together. The main focus was on the use of the Rhode Island Electronic Portfolio System (RIEPS) instance of Sakai, and many of the participants were associated Rhode Island K-12 schools and supporting agencies. There were also attendees, however, from other nearby state school districts, educational consortium, and higher-ed institutions, who are either already using Sakai themselves or were interested in learning more about Sakai. And, while portfolios were certainly a central topic of discussion, there were many examples of how Sakai's use in this community has expanded beyond just the portfolio tools.

One of the highlights of this conference I think was the participation of students, who were directly involved in several presentations. (Keep your eye out for the videos of these presentations, which should be appearing soon on the conference website soon.) I particularly enjoyed the session which provided an opportunity to talk in small groups with individual students about their portfolio experience. They were mostly students in their last year, soon to graduate, and had been using Sakai for the about two years. They walked us through their portfolios, how they assembled them, the various review processes involved, and showed off their nearly (school is almost over!) final product. It provided a very informative student-perspective that I seldom have the opportunity to hear, particularly at the K-12 level.

Presentations and conversations with the conference participants in general helped highlight a number of concerns that Sakai, with its roots in higher-education, has not considered in the same way as the K-12 community. For instance, the importance of moderation in communication settings, such as forums and social-networking, the length of time (13+ years!) over which a student's information needs to be maintained, and parental access to a student's records. Import things to keep in mind as we think about future work on Sakai. I hope participants from this conference, and other K-12 users, are able to volunteer some time to bring such a voice to discussions around Sakai 3.

The demonstration of the Sakai 3 prototype release was very well-received. In particular the content authoring capabilities seem a natural fit to the work the Rhode Island Technology Enhanced Science (RITES) project is doing with the Information Technology in Science Instruction (ITSI) application from the Concord Consortium. Their goal is to integrate inquiry-based science projects that use computational models and real-time data acquisition widgets and gadgets into the RIEPS Sakai instance. The Sakai 3 content authoring environment will help them focus on those gadgets and widgets, without having to build their own content authoring system.

I hope some of the presenters from RINET 2009 will bring their presentations to the 10th International Sakai Conference, just a few months away now, in Boston (7-10 July 2009). Its a great venue at which to bring together the K-12 voice with the larger community. See you next year at RINET 2010...

For quite a long time users of Sakai's Confluence and Jira instances would experience problems with pages not completely loading or a connection reset error would be generated almost instantly. A reload or refresh request – sometimes multiple ones were necessary – would get you past those problems. The frequency of such errors was particularly problematic for folks who were not well connected network-wise to the servers, such as overseas members of the communities or those working from coffee shops or other shared-network locations.

As of around mid-February 2009, the University of California, Berkeley, which hosts these servers believe they found the configuration problem upstream from the Confluence and Jira servers and have fixed it. This has been confirmed by a few reports from around the community since that time. So, if you've been avoiding using Confluence and Jira as part of your community collaboration because of those past problems, its now safe to return. (If you are still experiencing any problems like the ones described above, please email or to let us know, and provide as much information as possible regarding the URL you're trying to access, from what IP, at what time, etc.)

Looking further into the future of Sakai's Confluence and Jira servers, we are expecting to migrate the services from the current location, hosted by the University of California, Berkeley, to a commercial hosting service. We have run into problems transferring Confluence content that are currently preventing the migration, however, we are working with Atlassian and our current and future hosts to find a workaround. In the meantime, we are also working to archive out-of-date information that is no longer relevant from Confluence to off-line storage, as the problems are related to overall amount of content we currently have in Confluence.

Late Changes to Sakai 2.6

As we wind down toward the final release of Sakai 2.6, there are a couple late changes being made. Usually we are down to focusing only on bug-fixes and performance improvements at this stage, however, these two issues warranted further action and functionality change exceptions to our feature/code freeze rule:

  1. A minor improvement in the authz code ( SAK-15753 - Getting issue details... STATUS and KNL-130 - Getting issue details... STATUS ), which updates the isAllowed(String, String, Collection) function located in the file. To paraphrase from the Jiras (and see also the email thread that generated community discussion and lazy-consensus to make the change):

    Previously it only checked the base site id (e.g. /site/sideId) for permissions on the role instead of all of the realms that were passed into the Collection, which the normal use case does in a big nested SQL statement. This caused the Podcast bug linked to this jira to not work 100% correctly since the key realm to check was something like: /content/group/siteId/Podcasts/. So this new approach will make sure every realm passed into this function will get checked for permissions in the role that's being requested. It is also prioritized to check the /site/siteId realm first since that is where a true return will happen a vast majority of the time.

  2. Adding support for WYSIWYG editor option (i.e., FCK Editor) to the Wiki tool hasn't been completed successfully. So currently the focus is on evaluating possible options for the release, such as backing out the incomplete, non-working functionality, or attempting a different implementation approach that worked as a patch in Sakai 2.5 (and determining if it is compatible with other 2.6 changes in Wiki.)

As we explore options for migrating Jira and Confluence to a new host, one of the main obstacles we've encountered is Confluence's inability to export a useful backup for migration. Sakai's Confluence has accumulated too much content for the regular XML backup mechanism to work. We've been exploring alternative options for a direct db export, however, we are will likely also be moving from Oracle to MySQL, which complicates matters. Atlassian hasn't been able to find a solution either; other than suggesting we back-up each space individually and move them one-by-one, which likely would mean extended, multi-day down-time or a period when changes to content would not be reliably preserved and migrated.

Over the last several weeks we've archived and removed over 150MB of old content, including the venerable but dated Sakaipedia (preserving a few useful thing by migrating them to the appropriate Building/Deploying/Using Sakai spaces.) That's still not enough for a successful back-up though. So time to look for more dated material to delete... If anyone has time and expertise to help clean out or re-organize other spaces in Sakai's Confluence, please let me know.

As many people have already noted, Collab, the Sakai instance supporting community collaboration, has been experiencing email problems this week. Unfortunately we can't send an email out to let everyone know, as our announcements list is located on Collab, so I thought a blog post would help let everyone know that they don't need to email me personally to report the problem (smile)

Our colleagues at the University of the Highlands and Islands in Scotland, which hosts Collab for the Sakai community, are working to address the problems, however, they are part of wider, campus-wide problems they are currently dealing with. Hopefully service can be restored soon.

List emails are still being received by Collab sites and are being archived just fine. The problem is with outbound emails. A good portion of the outbound email is getting hung up somewhere between Collab and the intended recipients.

In the meantime, you can use the Email Archive tool in each site to stay up-to-date on the email list for that site. Also, after normal service is restored, I would encourage folks to re-send important emails.

oXygen XML Editor

Recently Chris Maurer investigated the licensing on the <oXygen/> XML Editor, and we've been able to obtain free licenses for core Sakai developers. What is it? To quote from their web page:

<oXygen/> XML Editor provides the best coverage of today's XML technologies; it complies with the established standards released by W3C and other organizations and enhances developer productivity through an intuitive and innovative XML IDE. <oXygen/> XML Editor provides the tools for XML authoring, XML conversion, XML Schema, DTD, Relax NG and Schematron development, XPath, XSLT, XQuery debugging, SOAP and WSDL testing. Integration with the XML document repositories is made through WebDAV, Subversion and S/FTP protocols. <oXygen/> also has support to browse, manage and query native XML and relational databases.

If you are interested in obtaining a license, please let me know. In order to qualify, you must have appropriate contributor licensing agreements on-file and be developing code intended for a Sakai release.

For those looking to get started with Sakai 3/Kernel 2 development, Ian Boston has just put together a nice, brief how-to on writing webapps with kernel 2.

Sakai 3.0.0 Milestone 1 (Demo Release)

Sakai 3.0.0 Milestone 1 has been released for demonstration and evaluation purposes only. This release has not been subjected to any formal Quality Assurance (QA) testing, and should not be used in production. It offers an opportunity to experience some of the initial and exciting User Experience (UX) work targeted at Sakai 3. It does not yet fully illustrate the reorganization of content and tool functionality that realizes the "everything is content" vision for Sakai 3. Those capabilities will be furthered with the switch to using Sakai Kernel 2 in the coming weeks. (This milestone release is still based on Sakai Kernel 1, which is the same as used in the current Sakai 2 series of releases.)

What you see in this milestone release will continue to evolve significantly as work progresses and feedback is provided. In its final form Sakai 3 will end up significantly different from Sakai 2.

The main goals of this milestone release are to:

  • catalyze community discussion and interest in helping further the design and development of Sakai 3 capabilities, and
  • support user-testing of some of the initial Sakai 3 designs and conceptual approaches

For more information on Sakai 3 in general, a good starting place is the 3akai page. (If you don't wish to build and run this milestone release yourself, then you can give it a try on the 3akai demo server, though this server is rebuilt from time-to-time so your content may not persist.)

One of the keys to improving the Sakai UX for Sakai 3 is to surface and re-use subsets of tool content and interaction capabilities via "widgets", rather than only through the monolithic tools' "pages". (For more about Sakai 3, visit the 3akai demo server.) The Authoring Working Group in Sakai has been discussing over the last several weeks what tool content it would be good to make available in this new way, and has compiled a table listing suggested tools and content on which to focus. Meanwhile, Anthony Whyte, with assistance of others in the community, has put together a technical how-to for developers describing the general principles behind adding RESTful access to tools in order to enable these new UX approaches.

So now the question becomes one of finding interested volunteers on the existing tool projects or in the community in general who can help out. As you can see from the last column in the table there are already a couple tools being worked on, however, there are a lot more – including ones that didn't come up in discussion yet – that need volunteers. If you are interested in helping out with this effort, please contact me.

Yaft is a new forum tool available for Sakai from Lancaster University. The name Yaft is derived from Yet Another Forum Tool, though it can easily be rebranded in the user interface. Yaft was designed and built through a requirements gathering process at Lancaster, with an emphasis on simplicity and clarity. Its available in Contrib, and is compatible with Sakai 2.5.x. (It will likely also work without much effort in Sakai 2.6 as well.)

From Yaft's overview of its features:

  • Simplicity - The user interface is designed to be simple, and the workflows of creating forums, discussions and messages have been considered throughout.
  • Different view modes - Discussions can be viewed in two hierachical modes, full and minimal. Full shows you the works, whilst minimal gets more messages on the screen without compromising navigation.
  • Fast - Yaft uses a combination of compact JSON data feeds and client-side rendering, using JavaScript and Trimpath templates. It's easy on the network and the server's processor.
  • RESTful - Most links can be bookmarked and passed around. All the content or data in Yaft can be retrieved via RESTful URLs.
  • Ability to easily move discussions around between forums.
Sakai 2.6 Update

Sakai 2.6 passed a major milestone in its progress towards official release in February 2009 today with the University of Cape Town (UCT) announcing it has deployed an early version in production. UCT certainly deserves a great deal of thanks for being an early adopter and significant contributor to QA, bug-fixing, and managing the 2.6 code.

There is still a lot of QA work and bug-fixing to do between now and February though, so if you have time, please consider helping out, particularly with testing, and get in touch with the Sakai QA Coordinator, Peter Peterson. (As of earlier today, Jira indicates 848 Bugs have already been addressed for Sakai 2.6).

The University of Cape Town (South Africa) and Psybergate have reached their first milestone in developing a SMS (text-messaging) tool and service for Sakai. The goals for this milestone were to define the APIs and database schema for the SMS service. Community review of this initial work is being sought by Monday, 15 December 2008, and should be directed to Stephen Marquard.

Completion of this project is expected around March 2009. It will be compatible with recent releases in the Sakai 2.x series and requires integration with your choice of external SMPP SMS gateway through standard APIs. It will also include an example integration of the service with the Announcements tool. Other projects interested in incorporating SMS capabilities are encouraged to get involved early and to contact the project lead, Stephen Marquard.

Stephen Marquard has contributed a nice, simple profiling script that developers can easily make use of to help identify potential bottlenecks in their code. I've copied his email to the sakai-dev list, which describes this handy tool and how to use it with various versions of Sakai. (For Sakai committers working on core code and interested in a more complex solution, and who are covered by Sakai contributor's licensing agreements, YourKit kindly provides free licenses for their Java Profiler.)

Hi all,

Historically, one of the most common causes of Sakai performance issues has been excessive volume of db queries generated by tools or underlying services.

I have created a simple profiling script which will show db queries and elapsed time per http request from debug and profile information logged to catalina.out, either historically or live.

This could be run against the QA server log files for example, or as a developer or QA tester, you can run this against a local instance of Sakai. Now it's easier than ever to verify that your code will not cause performance problems in production, without the overhead of complex solutions such as JProfiler.

The script is at:

This is currently usable with trunk (or cafe trunk) against the trunk kernel with mysql (as it uses SQL profiling in the mysql connector to log the SQL statements to catalina.out). Once a new kernel 1.0.x release is made and 2-6-x is updated to use that, you can also use this technique with 2-6-x.

If you're impatient or would like to run this against 2-5-x or earlier builds, you can do so by applying this change to tool/tool-util/servlet/src/java/org/sakaiproject/util/
A sample output line is like this:

http-8080-Processor24 64 16539 sakai.siteinfo f377813f-7896-454b-ac5c-c343ce6ccb56 GET
showing a request thread for Site Info which executed 64 queries in 16539 ms. (The elapsed time includes time to send to the client, so is only really a good performance metric if you're running this on a fast local network or the same machine.)

Hope this is valuable. If you do use it and find it of use, please let me know. We will be using it to test our candidate 2-6-x production build.

For bonus points, idle developers like Chuck (smile) are invited to hack up a Python app to feed this into a REST data source usable by the Google Visualization API (


Earlier this week a number of folks working on the next version of the Sakai kernel (K2) and the User Experience (UX) Improvement project met at the University of California - Davis. A lot has been happening in both of these areas, and this face-to-face meeting provided an opportunity to coordinate activites and move things along quickly, as well as to being formalizing some of the ideas and commitments into plans for future Sakai releases. (Notes and audio from these meetings can be found in Confluence and the K2 Google Group area.) A lot continues to happen in these areas now that the meetings are over and things are continuing to evolve rapidly – some of what you read below may already be out-of-date! – so stay tuned!

With Sakai 2.6 the kernel was separated out from the release itself into a version 1.0 kernel (or K1), which provides the back-end framework to support the tools and services of Sakai 2.6. Future releases in the 2.x will also be based on the 1.x kernel series. Work is also being done on an initial release for the 3.x Sakai series that will re-organize and enhance Sakai functionality into a less tool-/site-centric view and be more capability-focused. It is likely to include an extensive re-design of the user interface, significant improvements in content authoring and management, support for groups outside of the site context, simple URLs, and social networking capabilities, as well as some initial support for legacy Sakai functionality to ease the transition. It is likely that the 3.x releases will be based on K2 in the future, which will provide the reorganization and enhancements in back-end services necessary to support some of these capabilities. The 3.x series should not be considered initially dependent on K2, however, and may be actualized in stages as those capabilities become available.

An initial release candidate for Sakai 3.x will likely reach code freeze in March 2009 for use in July by Cambridge University and Georgia Tech as early adopters (and certainly anyone else who is interested). This initial release candidate is likely to have only a subset of final Sakai 3.0 capabilities, but provides an important opportunity to gain experience with the new code base in production early on. K2 meanwhile is hoped to be mostly completed in the coming months. If is not, then what is in the initial Sakai 3.x release candidate will be adjusted accordingly; for instance, support for groups outside of sites may be postponed.

For those currently invested in production or piloting of the Sakai 2.x series or those looking to adopt Sakai in the coming year, some of these capabilities can also be realized in a Sakai 2.7 release. The timeline for such a release would be similar to the initial 3.0 release candidate, with a code freeze around March 2009 and a release around July 2009. This is sooner than the once-a-year 2.x series releases done between 2.4, 2.5, and 2.6; however, it would also be limited in scope, with a relatively easy migration or adoption path. Such a Sakai 2.7 would allow us, however, to leverage the work being done for 3.x on UX Improvement and page authoring, as the initial work in this area will likely be relatively portable between the 2.x and 3.x series.

Those working on UX improvement and page authoring for 3.x are willing to do a little extra work to make this possible for a 2.7. Should larger difficulties arise, however, it would neccessary to have additional help from others in the community to keep the 2.7 effort on track. If your organization might be interested in this sort of 2.7, either as an upgrade or for new adoption, I'd be like to hear from you. And, of course, the more folks willing to pitch in on these projects, the more that can be accomplished for 2.7 (and 3.0)

In addition, such a 2.7 would also provide an opportunity for project teams to roll-out a set of minor, though coherent improvements and tweaks to the current 2.x series tool set. There are certainly already some nice enhancements in trunk that could be incorporated in such a release. If your project team has functionality they would like to include in 2.7, which is compatible with the proposed timeframe, please let me know.

Other enhancements, which need more time to complete or for proper integration, would still be on track for a 2.8 release in early 2010. Sakai 2.8 will likely be the last release in the 2.x series, though it will be supported with subsequent maintenance releases.