Hi Arvind, Thanks for sending this. I thought it was quite a nice reminder of the state the OAE project was in a year ago.
It's probably worth noting that the project has in the meantime been moving in what I consider to be a very positive direction, being a scalable, multi-tenant platform for academic collaboration. A number of progress reports [1, 2, 3] have been produced that describe this progress, and we have also had our first set of releases [4] that are currently being used in production by a number of institutions around the world. Obviously, the code bases for the UI [5] and back-end [6] are publicly available, and we'd welcome any feedback or contributions that you might be able to offer. [1] https://oae-community.sakaiproject.org/p/oQsGlrMQaa/November%20Progress%20Report.pdf [2] https://oae-community.sakaiproject.org/p/oQUSwec4mg/Christmas%20Progress%20Report.pdf [3] https://oae-community.sakaiproject.org/p/pYK6vy0eie/April%20Progress%20Report.pdf [4] https://github.com/oaeproject/Hilary/wiki [5] https://github.com/oaeproject/3akai-ux [6] https://github.com/oaeproject/Hilary Kind regards, Nicolaas Matthijs On 26 Sep 2013, at 14:09, Arvind Gupta <arvind.bernau...@gmail.com> wrote: > 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
_______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
