System

Last updated: 2026-03-12 v04

system_en.html

This document explains how the MyAnythingList system is deployed, hosted, archived, and maintained operationally.

Architecture describes how the software works internally. System describes how it runs in the real world.

1. Hosting Philosophy

The system is intentionally designed to run on simple infrastructure.

• Static hosting is preferred whenever possible.
• Complex server frameworks are avoided.
• CPU-heavy server processing should be minimized.
• Client-side logic performs most rendering.

2. Typical Hosting Architecture

Authoring VPS
      ↓
Build / Testing
      ↓
Static publish
      ↓
S3 or CDN hosting
      ↓
Public browsers / kiosks

• Authoring and mastering occur on a development VPS.
• Public content may be served from object storage.
• CDNs may be used for global distribution.

3. Documentation Tree

_docs/
   index-docs.html
   en/
      index_en.html
      requirements_en.html
      architecture_en.html
      system_en.html
      developer_en.html
      vision_en.html

• Each language has its own folder.
• Documents are directly browsable.
• File system transparency is intentional.

4. Multilingual Documentation

The documentation architecture is designed for translation.

• English documents act as the canonical source.
• Other languages mirror the same structure.
• Translations may be human or AI assisted.

_docs/
   en/
   es/
   fr/
   de/
   zh/

5. Static Deployment

The player itself is a static HTML + JavaScript application.

• No database is required.
• No backend runtime is required.
• Static hosting platforms can serve the entire application.

6. Logging

Usage can be monitored using normal web server logs.

Examples:

• Apache access logs
• S3 access logs
• CDN request logs

These logs allow operators to see:

• player usage
• playlist loading
• bot activity
• traffic sources

7. Daily Builds

Development builds may be archived in dated directories.

Example:

beta/
   _daily-builds/
      2026-03-11/
      2026-03-12/

These builds provide transparency into development progress.

8. Public Mirrors

The project is intentionally mirror-friendly.

• Static file trees can be mirrored easily.
• Documentation folders can be copied directly.
• S3 object trees can act as distributed mirrors.

10. Current Rendering Risks

• Startup QR state can appear in the wrong position before correcting later. This is tracked as a first-paint correctness bug.
• Visible-first rendering is required so that in-view content paints immediately while off-screen work continues afterward.
• URL art export is not yet pixel-perfect WYSIWYG relative to the live tile and remains a tracked output-fidelity issue.

9. Operational Goal