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
_______________________________________________
oae-dev mailing list
oae-dev@collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
