[Using Sakai] [oae-dev] Thoughts on Sakai OAE update

[Arvind Gupta]

Hi Mustansar
                    I agree with you, and instead of  using JSF/RSF, Nosql,
we should also incorporate new technologies, though it will required major
refactoring effort, but in the end will justified the effort. Looking
forward to more direction from you.

-arvind


On Sat, Oct 20, 2012 at 5:10 PM, Mustansar Mehmood <mustansar at rice.edu>wrote:

>  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 at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-user/attachments/20130926/78e2826b/attachment.html