Forum OpenACS Development: Re: Apache support critical

Don, let me start with your more "cynical side" first. I think you would come down strongly on the other side of the same argument if we simply substituted "AOLServer" for "Sakai" and "Apache" for ".LRN." If AOLServer's plumbing is so good, how come it has fewer mods than Apache? But that's not even the right analogy, because unlike AOLServer, Sakai has not been around for very long. A good comparison might be to the .LRN precursor ACES. Both ACES and Sakai are first-generation extensions of older, stable platforms. In the case of ACES, it was a new LMS wired together from mostly mature ACS modules. Likewise, Sakai is basically UMichigan's CHEF LMS (you know...Chef Sakai...the Iron CHEF Japan...get it?) stuck in uPortal with some extra wiring, where most of the effort of the project known as Sakai has gone into making that wiring something robust to build on rather than adding to the end-user applications. Sakai version 1.0 only came out four months ago, in October. And having been able to watch the early development of both ACES/.LRN and Sakai, I can say with great confidence that the early growth of Sakai far exceeds that of ACES. When Sakai is as old as .LRN is now, I have every reason to believe that it will surpass .LRN in the number of applications available. There are simply far more developer resources going into that community than into this one. The four founding schools alone have committed a total of at least 20 full-time developers.

On the issue of integration versus building from scratch...as you know, I'm not a technologist. I could say that the technologists here at the SUNY Learning Network, whose kung fu I greatly respect, are not terribly worried about making mix-and-match integration work so long as all the components start with uPortal on the front end (including single sign-on support) and Oracle on the back end. But rather than just basing this on a battle of the experts, let's try a use case out and see where it gets us.

Suppose an organization using Sakai wants to add the .LRN learning object repository--something that Sakai doesn't currently have. What would it take to have some meaningful level of integration? Well, if all you had was the ability to display through the uPortal framework and identify users with single sign-on, that would be a good start. Professors could go into .LRN, configure the repository for the users and display the links from the repository in the Sakai class portlet.

Of course, you'd be asking them to administer two systems. What would be really helpful is if you built a bridge mapping the Sakai groups/classes to .LRN groups/classes. That way, a .LRN LORs instance could be automatically set up with appropriate permissions for the class.

I suspect that just providing these services, i.e., .LRN publishing to uPortal channels, .LRN acceptance of single sign-on, and mapping of Sakai groups to .LRN groups, would be enough to cover most basic application integration. (And correct me if I'm wrong here, but I believe that two of these three pieces are at least partially done.)

Suppose, then, that a university were given these three integration points from the .LRN community. What might they still need to add themselves to feel satisfied with our LORS integration scenario? Well, they might want to build a portlet for LORS administration so that the professors don't have to go to the .LRN class control panel that contains mostly stuff that they don't use. Not a huge job, right? They might also want to add integration with a grade book. But LORS supports SCORM, and any decent grade book application should also support SCORM anyway. So that's not a huge deal, either. I can't think of anything else, off the top of my head.

It seems to me that this is hugely less work than building LORS from scratch in Sakai. Am I missing something?