I got the following question:
I think I’m most interested in what “stretching Sakai” to be a portal
would look like, a clearer picture of what the challenges and
solutions would be. Do you know someone in the community who is
trying to take this tack?
Here is my answer.
This could be two things:
(1) stretching Sakai to completely function *within* a portal such as uPortal – use uPortal’s layout AuthZ, etc
Because we promised this in the Mellon grant – I thought abut this for *years*. All my attempts failed – for lots of reasons – mostly because the CMS and Portal are just different beasts and one cannot contain the other. As best I can tell other than some exec types that saw this as sharing commonality and improving efficiency (this is sensible at a high level) – there was zero on-the-ground interest for this as best I could tell. Toward the end of the Sakai funding of uPortal we had a small group meeting where we worked all the details to make it possible to have uP 3.0 (sandbox) function as a LMS using Sakai tools. But there was never any interest in either technical community in working on this. Further – the portal community did not want an LMS becoming part of their portal. They have good technical reasons frankly. It really comes down to scalability – Portal folks want to scale to lots of clicks so they don’t want portlets with 10MB non-sticky sessions and they don’t want their portal JVMs to crash because an emedded application has a memory leak. The portal guys mostly want to pull RSS, XML, and JSON and show it in their rectangle – so they can be the dynamic bookmarking source for the campus like FaceBook. They can tune such a system nicely and keep unchanged release-wise for years because all the flexibility is in uploaded XSL style sheets (since they are not modifying data). The don’t want Sakai in their JVM any more than they want Peoplesoft in the uPortal JVM. Other issues like class loaders and frequency of upgrade of a CMS application also give the portal teams fits.
(2) stretching Sakai to function *as* a portal – effectively replacing uPortal
When we added JSR-168 support to Sakai – I began to imagine that Sakai could function as a simple organizational / small enterprise portal – I knew that Sakai would never challenge uPortal as an enterprise portal. The Sakai community would never make the significant investment needed to add the needed enterprise features that uPortal frankly already has in a very tasty form. Enterprise portal use cases are about eyeballs and getting content in front of eyeballs.
However I have strongly felt that in time, Sakai could function as a simple, basic workgroup portal – replacing a small Mambo, Drupal, or Joomla install for example. A few others follow me in this thinking – it is mostly Anthony (eat our own dogfood) and the research application folks like NCIBI where they have a single multipurpose server that meets both the outreach and collaboration needs. I wrote this up a while back:
https://source.sakaiproject.org/svn/reference/trunk/docs/architecture/sakai_workgroup_portal.doc
This approach has a long way to go – mostly uphill – I think it is a valid but small use case – I don’t put a lot of time in his use case – but I make a little progress here and there. Making the iFrame portlet frameless is one example of how Sakai can become a better “portal”. Another example is improving the RSS (news) tool to have more options to make it “pretty”.
———
When we put JSR-168 into Sakai – it was not my primary purpose to advance either of these use cases. I see JSR-168 support as a way to share functionality between enterprise portals and a CLE like Sakai – JSR-168 is one of Sakai’s supported plugins. uPortal has its iChannel portlets and JSR-168 plugins. Also remember that there are portable and non-portable JSR-168 portlets. Most rich portlets in uPortal depend on uPortal specific APIs and conventions. My goal for JSR168 support in Sakai was to support the simpler *portable* JSR-168 portlets – not the more complex non-portable JSR-168 portlets.
I have been developing a set of portlets that work in Sakai, uPortal, and GridSphere just for my own interest and to learn how to make portable portlets. Here are those portlets:
https://source.sakaiproject.org/contrib/portlets/trunk/
JSR-168 also provides a standard way to have multiple interactive independent rectangles on the same screen like our home page in Sakai. So for example if we had resources – we should rewrite all the synoptic tools as portlets *immediately*. The home page would then lose its frames in an instant! The nice thing is that the Velocity/Jetspeed portlets that came from CHEF have the exact same data model as portlets – I am slowly working on a shim that might allow all of the velocity tools to become portlets and thus become iFrame-free. I am laying the foundation for generalizing the switch of Velocity tools in Sakai to JSR-168 – starting with my experiments with the iFrame tool. Helpers are an issue. So my next tool to portletize might be the mail tool.
All a bunch of work for which I simply have too little time :)