1. Introduction

Following chapters briefly describe what ModWeb delivers for each party involved.

  • Organizations providing services
  • Developers developing services
  • System administrators maintaining services
  • End users using services
  • Developers developing ModWeb

1.1. Organizations providing services

Modweb aims to provide a service environment that:

  • is scalable: from single host to multi-head and -db environment
  • cost effective
  • can integrate open source projects and in-house projects seamlessly
  • clear skill separation: database admins, application coding and artists
  • has long, predictable and controllable life-spans for projects

Cost effectivness:

  • fast deployments: modules and package management are fast to deploy
  • supports the princible of limited set of core technologies, less people needed
  • utilizes open source software


  • if wanted, enforces sub-contractors to make strict implementations
  • releases are planned in long-term use in mind
  • maintain a list of add-ons at ModWeb to predict their lifespan surviality
    • provide an automatic kill functionality for dangerous add-ons

1.2. Developers developing services

  • There should be a modular drop-dir architechture for adding features/applications into site
  • ModWeb should provide basic services for modules:
    • Automatic menu to add visual access to module
  • Embrace use of SQL-database for everyting by providing a simple, low-burden ORM
    • use native SQL-datatypes instead of dumping in and out large preformatted blobs

1.3. System administrators

Modweb’s intended users are service or system owners who use dominating UNIX-like operating systems as their service platforms.

install software using system’s package management system.

  • support binary package installation without manual configuration
  • break functionality into modular components
  • allow installation
  • expect that updates can be deployed with package management
    • make sure that code compatible for upgrade and downgrade, or do conversions
    • keep tight tracking of db-schemas and application APIs.
    • trigger required conversions in package post installation, forth and back in small steps

1.4. End users in the net

  • Should get more technical information what might cause possible problems in their experience
  • provide tools for service- and client side validation and problem reporting

1.5. ModWeb Developers