Stuart Sim over at Java.net has a blog post clarifying the current state of SAKAI’s development. The SAKAI team could do itself a huge favor by issuing this kind of an update summary itself on a regular basis rather than relying on the small handful of informed outsiders who are capable of making this kind of evaluation.
Some highlights:
It’s not fair to evaluate the current release candidate against the goals of the SAKAI program. It is widely accepted that these aims will not be realized until version 2.0 in the spring/summer of next year. The current release is a snapshot of the code base that will be deployed at the leading SAKAI contributing universities. This fact alone is a testament to the practical and real world applicability of the solution….
(Snip.)
The problem is that the ‘open framework’ is already showing signs of the real world constraints it inherited for deployment. In every software project, the challenges of interoperability and deployment are at odds and compromises have to be made.
Much of the constraints inherited from both Chef (open source collaboration tool) and uPortal (open source portal) are evident in the current code snapshot and it will take some time and effort to unwind them.
SAKAI uses the Spring Framework to define the loose coupling between components in the framework. The use of Spring and similar lightweight containers is a good approach for loose binding components without the need for a full J2EE container. What is not clear is the value the SAKAI framework would provide over an above Spring itself. Spring is a development framework and, it it’s current state, so is SAKAI….
On this last point, I’d love to get some further clarification. I’m not familiar with Spring; how lightweight is it, really? Is it just lightweight in comparison to J2EE? Where does it set the bar for a programmer who wants to add new components or extend the framework?