<< MirOverview

---

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

Mir design/development/documentation/etc goals

meta-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

meta-questions

• 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)
  • components suggestion: http://lists.indymedia.org/pipermail/mir-coders/2005-August/0821-p0.html
  • risks with too much modularity (cf dada): http://lists.indymedia.org/pipermail/mir-coders/2005-August/0821-6e.html
• 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.

to top