| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| start [2025/10/21 14:38] – [What is Moogwai ?] admin | start [2026/11/09 08:16] (current) – external edit 127.0.0.1 |
|---|
| | {{ ::moogwai_brand_big.png?600 |}} |
| | |
| | ====What is Moogwai ?==== |
| | |
| | **Moogwai**<sup>TM</sup> 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**<sup>TM</sup> is a project based on **Moodle**<sup>TM</sup>, which is one of the top world software in the education field. |
| | |
| | ====Is Moogwai a fork of Moodle ?==== |
| | |
| | In **NO WAY** **Moogway**<sup>TM</sup> pretends to be a fork of **Moodle**<sup>TM</sup>. We love **Moodle**<sup>TM</sup> 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**<sup>TM</sup>'s technical maturity. |
| | |
| | Although **Moogwai**<sup>TM</sup>'s API are very closely inspired from **Moodle**<sup>TM</sup> APIs, do not hope **Moogwai**<sup>TM</sup> is a concurrent LMS to **Moodle**<sup>TM</sup>. **Moodle**<sup>TM</sup> did (and still do) things well, and is now a very mature framework for education. **Moogwai**<sup>TM</sup> is focussing on everything wich **is NOT** an LMS. |
| | |
| | ====Who is it intended for ?==== |
| | |
| | **Moogwai**<sup>TM</sup> is addressing Web Application developers that have a good skill in **Moodle**<sup>TM</sup>, love the framework, and would like to pursue developing other applications without changing of technical culture. **Moogwai**<sup>TM</sup> sticks to a lot of core **Moodle**<sup>TM</sup> concepts, rearrange them, and sometime extends them. |
| | |
| | **Moogwai**<sup>TM</sup> would be a perfect generic framework for any IT company that provides **Moodle**<sup>TM</sup> services, but might also serve companies that are **NOT** related to education. |
| | |
| | ====What is in Moogwai ?==== |
| | |
| | **Moogwai**<sup>TM</sup> has been developed sticking to **Moodle**<sup>TM</sup> 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 |
| | |
| | |
| | [[:rationale_and_design|See architectural rationale and discussion]] |
| | |
| | [[:licensing|Moogwai Licensing discussion]] |
| | |
| | [[:moodlevsmoogwaiconceptmap|See Moodle vs Moogwai concept map]] |
| | |
| | [[:apis|Technical documentation and APIs]] |
| | |
| | ====What has been removed vs. Moodle ?==== |
| | |
| | **Moogwai**<sup>TM</sup> 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 [[:blocks:rationale|rationale]] of this choice). |
| | |
| | ====New concepts in Moogwai==== |
| | |
| | ===New plugin set: app=== |
| | |
| | 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=== |
| | |
| | Contexts is a single abstraction to unify any object or subconcept that needs to be driven by roles or profile restrictions. |
| | |
| | ==Quick reminders of the original concepts== |
| | |
| | * 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. |
| | |
| | ==What is changing== |
| | * 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 ====== |
| | |
| | **Moogwai Apps** is the core concept of **Moogwai<sup>TM</sup>** : An App is a functional singleton that provides a service or application to users. Here are some exemples of apps : |
| | |
| | * **[[apps:welcome|Welcome app]]** : A simple demo application provinding a Welcome Landing page. |
| | * **[[apps:moodleload|Moodle load service]]** : A service online allowing setting up and running load tests on **Moodle<sup>TM</sup>**. |
| | * **[[apps:subscribe|Subscribe app]]** : An app providing a simple subscription mechanism to any service or app. |
| | * **[[apps:shop|Shop app]]** : A full integrated shop working with events, webservices, and integrated pruchase handlers. |
| | |
| | ===Apps and "Locals"=== |
| | |
| | **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. |
| | |
| | ====How to get Moogwai==== |
| | |
| | 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//. |
| | |
| | ====Roadmap==== |
| | |
| | * 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 |
| |