[Using Sakai] Thoughts on Sakai OAE update

[Mustansar Mehmood]

Dear Sakaigers,

Reading recent OAE project status update as well as proposed future 
directions still hint a sketchy future for OAE. There have been 
ambitious attempts at Sakai to come up with new technologies e.g. RSF 
and fluid project and other introduced bleeding edge technologies like 
OSGi. Such ventures had limited success in moving Sakai forward 
sometimes because of

(i)Working on building new frameworks which may be out of scope of Sakai 
project

(ii)Working with technology with not widely know outcomes for large 
scale projects

(iii)Using technologies and architectures which may hinder third party 
open source evangelists to contribute easily

Since Sakai CLE has a great ecosystem as well as an amazing working 
codebase, I wonder if there is a possibility to morph Sakai CLE into 
Sakai OAE. CLE and OAE may not share the same design goals; however 
there may be room to have similar behavior. Sakai CLE has changed 
significantly since OAE was initially envisioned, especially due to 
introduction of great tools like dashboard, lesson builder and profile2 etc.

·I think OAE project or the functionality should be built as an 
extension of CLE instead of an independent rewrite project so that it 
remains relevant even during its period of active development. As a long 
as SOA philosophies are kept in mind, merging and branching should be 
painless.

·With merger of Jasig and Sakai, perhaps uportal artifacts could be used 
(embedded) with in Sakai instead of apache pluto hence moving to greener 
pastures of JSR-286 and a chance to take advantage of great uportal 
innovations.

·Separate core services like kernel and site management stuff from tools 
in a way that institutions could choose the tools they want to run. For 
instance at the moment samigo and OSP are part of the default Sakai even 
if there is no samigo tool in the source (by deleting the source) the 
dependencies are found in maven and hence in tomcat.Not that there is a 
chance that institutions wouldn't want to use samigo but keeping a clear 
boundary between tools and core services is important to give 
institutions a chance to finely customized application and server load 
on their system. There may be dependencies between the tools like Samigo 
depending on Gradebook etc. These dependencies should be clearly 
documented. Currently the CLE codebase is getting close to one GB and it 
may become intractable if tools keeping coming at this pace with major 
extension project (OAE) in the making.

·Making Sakai as compliant to major JSR's and other industry standard as 
practical to open doors for developer who may know the technologies and 
not necessarily the Sakai way.

·If search or other features can be best implemented using a NoSQL 
database, as long as it is an optional part of the setup, institutions 
seeing the benefits of such option are unlikely to resist an additional 
set of servers for added functionality. At a later stage RDMS used in 
CLE may be able to pass on its duties to the NoSQL 
database(Cassandra/MongoDB) depending on the need and trend.
Similarly if Node.js is the best option to offer some of the desired 
functionalities there is no harm is using it and again keeping that 
aspect of Sakai optional until community finds is production ready and 
useful for most cases.

·Making skin for desktop "completely" independent of the mobile/tablet 
version may help designers to work on smaller independent user 
interfaces. As of now there is a pda.css typically shipped with along 
with the desktop skin

·As far as the cloud friendliness of the project is concerned I believe 
continual refactoring and new technologies coming up would ease Sakai's 
way into the cloud. At least for the storage using cloud or not is a 
matter of institutional policy than technology perhaps similar argument 
could be made in case of database RDMS or NoSQL

·Eventually success of an open source project is a function of 
willingness and readiness of the contributing community, while there is 
no clear path that leads to their willingness however having clear and 
detailed documentation, minimal technical debt and adherence to 
standards as much as possible may leads to increased readiness of 
potential contributors

Best Regards,
Mustansar Mehmood

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-user/attachments/20121020/ff76d85a/attachment-0001.html