Developer's Journal

Wednesday, May 6, 2009

Often, when I'm trying to design some software, I write code to try out my ideas. Sometimes the design process itself produces some fairly useful code.

While kicking around my options for how to do conditional release better this time around, I ended up with a working port to trunk of the conditional release work I did for Georgia Tech. This one is also much-improved by some critical separation of concerns.

I have created a little Sakai distribution you can check out to put conditional release through its paces. It still needs work: there are some ugly things in the resources tool, and the API is still wildly in flux while I figure out the minimum useful cross-section.

But making it work forced me to think through some things, which I will be able to write up soon.

Here are the instructions for getting your very own conditional release:

Wednesday, March 25, 2009

I attended a webinar today that Michael Korcuska gave on a new proposal for the Sakai development process. The basic idea is that we will have more formal ideas about what stage a project is in. Those stages are R&D, Incubation, and Release. In order to get into the release (beginning with Sakai 2.7) it will be necessary to meet those standards of technical quality and project governance. I asked about Conditional Release, and Michael said the process would apply here. I think it's clear that the work produced for Georgia Tech falls into the R&D category. It will not be hard to meet the standard to move into Incubation, since I know this is functionality with interest (and commitment) from several institutions.

The open question now is how much more work will be involved for the code to be considered releasable. We'll have to get through the (yet to be empaneled) Sakai product council. I think this is a good test case.

As for the design, I've been learning about JavaScript; we'll need it for the capability to have a dynamic rule builder that anyone can use on any page. Once the design document is ready, I hope I can get feedback from some of our front-end experts.

I'm aiming to have the design document ready for review in mid-April. See you then.

Friday, February 27, 2009

When we went through the first design of conditional release, we worked up a complete notification system before we realized that we had designed exactly what's in the event/ module of Sakai. We were a little embarrassed, but it was ultimately good, because it meant we could use the code that was already there, and it meant I understood Sakai notifications pretty well by that point!

There were some things we needed to overhaul in the existing event system to make it work for our purpose. The most important of these was that although the underpinnings for persistence were there, nobody had ever needed a persistent Notification before, so it wasn't implemented. {{Notification}}s and the accompanying {{NotificationAction}}s are one of those things that gets stored in the Sakai database as a blob of XML. This has always struck me a little bit, shall we say, crazy, but the nice thing about it is that you can add to or change the definition of the data that gets stored with something, and you don't have to change a thing about the database schema.

As soon as I started thinking about conditional release again, I began to struggle with the dependencies. It's a pretty thorny problem: when is it ok to introduce a compile-time dependency, and how far can we get with run-time dependencies? I'll have more to say on this subject soon, but I realized that since so much of the conditions service is just dealing with Sakai events, I ought to just move the code into the event/ module. That's one less compile-time dependency we have to worry about, and no one has to get alarmed by me asking to add a new top-level module to the kernel.

Putting most of the code in event/ also eases much of the pressure of whether my code will be "promoted" from contrib to provisional status. If I'm just upgrading an existing module, I can happily work away without worrying that I'm introducing something New and Scary.

One of the things Sakai has taught me about growing a big software system, is that when you add something, you want people who don't need to use it to never even have to know it's there. You should never force people who don't care about your "special" code to apply a patch, or add dependencies to their pom.xml files just to keep their builds from breaking.

Now to get back the svn commit privileges I had before the kernel forked into its own project!

Tuesday, February 17, 2009

So it's official: Rutgers has put up some money to continue development of conditional release for Sakai, with the aim of getting it promoted from contrib to provisional status.

It's been a while since there was any conditional release news, so here is a little recap: The existing code was developed for Georgia Tech in the Sakai 2.4 timeframe. My mission is to update the system for Sakai trunk in time for consideration to be included in the 2.7 release.

Along the way, I will need to fix some problems for the feature to be promotion-worthy:

• I need to find a way to sever unwanted dependencies from ContentHosting to the conditions service, especially now that the content service is part of the separately-released kernel 1.x.
• I made heavy use of Sakai's NotificationService, which may or may not be getting replaced by some other events mechanism. I will explore the current landscape.
• For want of time, the changes to the Resources tool were uuuuugly. I need to cut way back on the shame factor.

Time permitting, I would also like to investigate the feasibility of adding another tool to the conditional release ecosystem, say Melete or Samigo. Conditional release is more useful the more it ties together available activities in Sakai.