<< MirOverview

(mostly from discussion August 2005: http://lists.indymedia.org/pipermail/mir-coders/2005-August)

Mir design/development/documentation/etc goals


  • build a real, active developer's community:
    • More coders? Or rarther more non-coders assisting mir users and mir customizers, sys-adminning servers, writing documentation / build templates, help out with release matters, etc.?
  • healthy, documented decision making process
  • need a release strategy
  • in general the organization of aspects should be improved


  • a huge code-level documentation effort for the actual code vs simpler design?

documentation goals

  • installation documentation and assistance needs a lot of improvement (MirInstallation)
  • no documentation for administrators, developers, customizers, etc

developer documentation goals

packaging goals

This is not strictly only documentation, since it requires developing scripts and understanding a GNU/Linux distribution, including security aspects: a package which is easy to install but also easy to install in a dangerous way (creating holes for exploits) due to inexperience or normal human forgetfulness is not a good idea
  • packages for standard GNU/Linux distributions - fedora, debian, gentoo

administrator documentation goals

(administrator: someone with access to a server who modifies files in the etc/ hierarchy for an imc on that server)
  • list of all possible fields in templates, and list of all possible options in producers.xml is most important
    • maybe generate this automatically using by creating a special producer (like freemarker and velocity producers)
  • eg. extratables should be documented

more concrete coding goals

  • more use of quality third-party, open-source libraries.
    • e.g. backend of mir using the hibernate persistence engine (idefix)
  • a more modular design (called "components" or "modules" in other CMS's)
  • alternatives to using a custom programing language for producers.xml
    • Why? Which things could not be done by a XML-based description?
  • an alternative "Localizer" framework
  • renaming certain terms
  • avoiding unnecessary design patterns (keeping things simple when possible)
  • some components aren't functioning properly: the database-layer, the media handling layer
  • easily extensible database schemas? cf. ruby (cf. SamizdatEngine)
    • The most current idea is to allow for custom extensions for every entityin the core mir model. Like, for every, say, article, there will be an article extension table that can be customized by local installations.
Topic revision: r1 - 22 Aug 2005, BouD
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback