https://mwiki.costasano.club/index.php?action=history&feed=atom&title=ICT%3ASystem_Strategy 2026-07-23T02:48:51Z Revision history for this page on the wiki MediaWiki 1.45.1 https://mwiki.costasano.club/index.php?title=ICT:System_Strategy&diff=391&oldid=prev 2026-02-04T18:03:52Z

<p>Created page with &quot;= Costa Sano MediaWiki – System Strategy and Architecture = __TOC__ == Purpose of this document == This page explains the &#039;&#039;design philosophy&#039;&#039; and &#039;&#039;architectural strategy&#039;&#039; of the Costa Sano information system. It answers: * Why MediaWiki? * Why namespaces? * Why Cargo + PageForms? * Why dashboards? * Why virtual machines? * Why this structure? Future maintainers should understand the reasoning, not only the configuration. The system was designed for: * long-ter...&quot;</p> <p><b>New page</b></p><div>= Costa Sano MediaWiki – System Strategy and Architecture =<br /> __TOC__<br /> <br /> == Purpose of this document ==<br /> This page explains the &#039;&#039;design philosophy&#039;&#039; and &#039;&#039;architectural strategy&#039;&#039; of the Costa Sano information system.<br /> <br /> It answers:<br /> <br /> * Why MediaWiki?<br /> * Why namespaces?<br /> * Why Cargo + PageForms?<br /> * Why dashboards?<br /> * Why virtual machines?<br /> * Why this structure?<br /> <br /> Future maintainers should understand the reasoning, not only the configuration.<br /> <br /> The system was designed for:<br /> * long-term stability<br /> * low cost<br /> * easy maintenance<br /> * non-technical users<br /> * independence from vendors<br /> <br /> ----<br /> <br /> == Core Principles ==<br /> <br /> === 1. Simplicity over cleverness ===<br /> The system must be:<br /> * boring<br /> * predictable<br /> * repeatable<br /> <br /> Clever or fashionable solutions were deliberately avoided.<br /> <br /> Boring systems survive longer.<br /> <br /> === 2. Open-source only ===<br /> No paid licenses or vendor lock-in.<br /> <br /> Reason:<br /> The club must survive with a limited budget.<br /> <br /> All core components are:<br /> * MediaWiki<br /> * MariaDB<br /> * Apache<br /> * Linux<br /> <br /> These are mature, stable, and free.<br /> <br /> === 3. Separation of concerns ===<br /> Each tool has a clear responsibility.<br /> <br /> * MediaWiki → structured knowledge system<br /> * Cargo → structured data storage<br /> * PageForms → data entry<br /> * WordPress → public publication<br /> * Virtual machines → isolation and portability<br /> <br /> Trying to make one tool do everything was intentionally avoided.<br /> <br /> ----<br /> <br /> == System Layers ==<br /> <br /> The system is organised in layers. Each layer is independent.<br /> <br /> === Layer 1 – Hardware ===<br /> Standard PC/server hardware.<br /> <br /> No special requirements.<br /> <br /> Must be easily replaceable.<br /> <br /> === Layer 2 – Virtualisation ===<br /> Hyper-V today, possibly Proxmox/Linux in future.<br /> <br /> Reason:<br /> * hardware independence<br /> * easy migration<br /> * easy backup<br /> * easy recovery<br /> <br /> VMs are copied, not rebuilt.<br /> <br /> === Layer 3 – Operating System ===<br /> Linux (AlmaLinux) preferred for long term.<br /> <br /> Reason:<br /> * no licenses<br /> * stability<br /> * low resource usage<br /> * long lifetime<br /> <br /> === Layer 4 – Web stack ===<br /> Apache + PHP + MariaDB<br /> <br /> Classic LAMP stack.<br /> <br /> Reason:<br /> * extremely stable<br /> * widely documented<br /> * easy for successors<br /> * works everywhere<br /> <br /> === Layer 5 – Application ===<br /> MediaWiki with extensions:<br /> * Cargo<br /> * PageForms<br /> * Lockdown<br /> <br /> Reason:<br /> Transforms MediaWiki from a wiki into a structured database application.<br /> <br /> ----<br /> <br /> == Why MediaWiki ==<br /> <br /> MediaWiki was chosen because it is:<br /> <br /> * mature (20+ years)<br /> * widely used<br /> * low resource requirements<br /> * open source<br /> * very extensible<br /> * future-proof<br /> <br /> Important:<br /> The goal is not a modern fancy UI.<br /> The goal is durability.<br /> <br /> MediaWiki is ideal for long-term knowledge preservation.<br /> <br /> ----<br /> <br /> == Why Cargo + PageForms ==<br /> <br /> === Cargo ===<br /> Adds database tables and structured queries.<br /> <br /> Provides:<br /> * typed fields<br /> * SQL-like queries<br /> * fast reports<br /> * clean data model<br /> <br /> === PageForms ===<br /> Adds:<br /> * forms<br /> * validation<br /> * controlled data entry<br /> * no wiki syntax for users<br /> <br /> Together they transform MediaWiki into:<br /> → a lightweight database application.<br /> <br /> ----<br /> <br /> == Why namespaces ==<br /> <br /> Namespaces are used for both organisation and security.<br /> <br /> === Structure ===<br /> * Research: → dashboards and UI<br /> * Chapter:, Place:, Organisation:, Asset: → data<br /> * ICT: → documentation<br /> <br /> === Benefits ===<br /> * clean separation<br /> * easier permissions<br /> * users never see technical pages<br /> * simpler navigation<br /> <br /> Users should only work in Research:.<br /> <br /> ----<br /> <br /> == Why dashboards ==<br /> <br /> Users never use:<br /> * Special pages<br /> * raw wiki editing<br /> * manual page creation<br /> <br /> Instead they use:<br /> * dashboards<br /> * buttons<br /> * forms<br /> <br /> Reason:<br /> Club members are not IT specialists.<br /> <br /> The system must behave like a normal application.<br /> <br /> ----<br /> <br /> == Design Workflow Pattern (for each entity) ==<br /> <br /> Each entity follows exactly the same pattern:<br /> <br /> # Template with #cargo_declare<br /> # PageForms form<br /> # Dashboard page<br /> # #formlink for editing<br /> # returnto dashboard<br /> <br /> This pattern must be reused without redesign.<br /> <br /> Consistency is more important than optimisation.<br /> <br /> ----<br /> <br /> == Architectural Philosophy ==<br /> <br /> The system was designed with the mindset:<br /> <br /> * survives hardware failure<br /> * survives maintainer change<br /> * survives budget constraints<br /> * survives 5–10+ years<br /> <br /> Technology choices were guided by longevity, not trendiness.<br /> <br /> If unsure, always choose:<br /> → simpler and older technology</div>

Mngr