Moodleload Load Test Service Online

Moogwai^TM is a core infrastructure helping developping Web applications with the benefit of a strong and mature middleware layer, solving most common issues a Web Front service addresses. Moogwai^TM is a project based on Moodle^TM, which is one of the top world software in the education field.

In NO WAY Moogway^TM pretends to be a fork of Moodle^TM. We love Moodle^TM and yet strongly support it as an active third party conributor. This is why we wanted to use a framework that let us continue think and drive development and integration projects taking profit of Moodle^TM's technical maturity.

Although Moogwai^TM's API are very closely inspired from Moodle^TM APIs, do not hope Moogwai^TM is a concurrent LMS to Moodle^TM. Moodle^TM did (and still do) things well, and is now a very mature framework for education. Moogwai^TM is focussing on everything wich is NOT an LMS.

Moogwai^TM is addressing Web Application developers that have a good skill in Moodle^TM, love the framework, and would like to pursue developing other applications without changing of technical culture. Moogwai^TM sticks to a lot of core Moodle^TM concepts, rearrange them, and sometime extends them.

Moogwai^TM would be a perfect generic framework for any IT company that provides Moodle^TM services, but might also serve companies that are NOT related to education.

Moogwai^TM has been developed sticking to Moodle^TM architecture, and removing everything that was addressing specific education needs. By the way, every part that has been elucidated to be generic to “any” Web app project has been kept in the architecture :

• Generic core APIs
• Database support (Only MySQL)
• Secured file storage with file manipulation API
• Modular architecture based on components (subsystems and plugins)
• Central administration
• Administration tools (generic parts)
• Central settings organisation
• Plugins installation and update process
• Modular distributed language management
• Modular distributed backup/restore strategy
• Webservices API
• Privacy and RGPD API
• Theming architecture
• Mustache templating and output API
• Context, roles, and capability ternary ACL model
• General Event and logging API
• Rating API
• Task API
• Security checks
• Reporting (generic parts)
• Authentication
• Content filtering (generic parts)
• Generic messaging
• Generic calendar (redrawn)
• “Local” container for uncategorized developements

See architectural rationale and discussion

Moogwai Licensing discussion

See Moodle vs Moogwai concept map

Technical documentation and APIs

Moogwai^TM has been reshaped entirely to discard :

• Course architecture (course categories, courses, course formats, etc)
• Course modules, modules will not be entirely removed, but refactored so they can attach to some adequate “context levels”.
• Grade API and grading book
• Enrolments
• Completion
• Question and quiz infrastructure
• Content bank and H5P infrastructure
• Learning analytics

By the way, we aimed at really simplify as much as possible the architecture and remove some over-complex features of Moodle, so we removed some generic parts :

• Blocks : Moogwai is NOT any more blocks aware (see the rationale of this choice).

Moogwai from scratch will just install the infrastructure, which means that end users will not find anything usable in it. Integrators will develop their local services as an instance of a new plugin class : the “App”. As we cannot anticipate on the complexity of what integrators will have to develop, a significant reshape of the role and capability system is added (See Contexts).

Contexts is a single abstraction to unify any object or subconcept that needs to be driven by roles or profile restrictions.

• Capability : A capability is an individual switch that will allow a user to “see” or “do” something in the application.
• Role : a role is a set of capabilities that will be switched “on” or forced “off” if the role is applied to the user in the current context.
• Context : A context is a part of the application where a role can be applied to a user. Contexts can be nested in other contexts to form an administation tree architecture.
• Context Level : A context is of some context level, designating the nature of the object it represents.

• In moogwai, any integrated “App” will be able to add context levels to moogwai, and manage dynamically its internal model in terms of role definition. Moogwai is not any more restricted to a static context level definition.

Moogwai Apps is the core concept of Moogwai^TM : An App is a functional singleton that provides a service or application to users. Here are some exemples of apps :

• Welcome app : A simple demo application provinding a Welcome Landing page.
• Moodle load service : A service online allowing setting up and running load tests on Moodle^TM.
• Subscribe app : An app providing a simple subscription mechanism to any service or app.
• Shop app : A full integrated shop working with events, webservices, and integrated pruchase handlers.

Moogwai Apps and Local plugins have some characteristics in common, such as being functional “singletons” (this may hide internal instanciability of some sub-objects). But they still have major differences :

• Apps are more deeply integrated in core, theme and global architecture (navigation, features organisation) than Locals are.
• “Local” keeps its original meaning, that is, a code garbage where to drop anything that cannot be better categorized or reserved to locally integrated specializations.
• Apps do accept the “custom contexts” concept. Locals DO NOT.

Moogwai continues to be in an experimental developping process is NOT YET publically available. Early interessed potential contributors might contact us at dev-At-moogwai.org.

• POC : Poof of concept (passed)
• Experimental (in progress) - ALPHA1
  • Yet work to do on the backup/restore process
  • Finalize application samples
• Consolidation - ALHPA2
  • Redraw Behats
  • Cleanout and redraw all unit tests
  • Industrialize repos and production workflow
  • Setup continuous integration and Test facility
• Application experimentation - BETA1
  • Finalize candidate applications
• Production release - RELEASE