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