 | Under Reconstruction |
Resources and Content
This space focuses on the user experience and tools focused on content management in Sakai. For service and architecture questions, see the Project: Content Hosting space.
History
Originally Sakai's support of file and content management was focused on the "Resources" tool and its cousins:
The service backing all of this is CHS (Content Hosting Service), which became a crucial support for a variety of new content tools which began to arrive on the scene after Sakai 1.5:
- Melete aims to better support views that structured content around learning units or modules. Although Melete remains a contrib tool, its feature set is fairly fundamental to a LMS, and it is commonly deployed along with the standard Sakai release.
- The OSP suite of tools has always been intimately connected with CHS and content management in Sakai, although primarily as a service matter.
The Resources tool continued to see design changes between the 2.0 and 2.5 releases, brought on by both technical pressures (e.g. the addition of new content types) and complaints about the user experience. At about the time of the 2.5 release two lines of thinking were coming to a head:
- The UX problems with Resources were fairly deep-seated (e.g. the conflation of file management and content presentation), and further evolutionary iterations could not hope to satisfy them. In fact these design iterations had stretched Resources to the breaking point. Although new features were needed (e.g. versioning) the legacy design could not accommodate this growth.
- A proliferation of new content-oriented tools was serving to indicate not just a dissatisfaction with Resources, but also an unavoidable breadth of value and purpose for content and how disparate audiences cared to work with it. This variegated tool set needed richer and better performant service support.
- CHS had become a fairly complex portion of the Sakai service layer that was difficult to maintain and troubleshoot, and there were other open source projects available (e.g. Jackrabbit implementing the JSR-170 API) which could take on this burden and bring in richer feature support (for the full rationale, see JCR rationale and implications ).
The development focus then turned first to the service layer - bringing in JCR support - while the Resources tool entered a kind of holding pattern. With a JCR implementation now included in Sakai releases as of 2.5, the focus is once again turning to those tools which depend on these services, and at the same time Rethinking Content Management in Sakai.
