Migration Implications

Implications for Resources and Legacy CHS

There are several arguments for minimizing further development in legacy Resources and CHS beyond the 2.5 release:

The Resources WG feels that the legacy tool has been pushed nearly as far as it can go with the current design, which is tightly interwoven with legacy CHS and the functionality it offers.
Further surgery within the Resources+CHS stack to shift to JCR storage would be both more difficult and more disruptive than developing bridging code to a new set of services (and a new set of JCR-based tools)
There has been a longstanding interest in redesigning how content management works in Sakai as a UX matter. A new set of content tools would provide more freedom to consider more significant set of changes than iterations on the legacy tools (e.g. Resources, Dropbox, and the attachment helpers) while at the same time allowing production schools greater flexibility for how aggressively these changes are adopted.

JCR Content Hosting Handler (CHH) can be used for legacy tool support, but it will be difficult to maintain JCR CHH if CHS continues to see development
If a content tool needs to have its content appear in legacy Resources (or its family of tools, including Dropbox and the legacy attachment helpers), it must be careful not to use JCR in a way that is incompatible with CHS
JCRService can be used directly by new content tools that do not need to have their content appear elsewhere in legacy tools