IMC Database Development Page

The current code of the IMC Database (aka Contact Database) is both lacking functionality and written in outdated style (register_globals). This page will be used to discuss its improvement.

Functionality

• Multiple access levels (DB admin, IMC master, IMC moderator, guest...), single accounts for each user
• Automatic password reminder
• Syndication of contact data: A way to integrate an IMCs' contact data stored in the DB to a local IMCs website (XML?)
  Your IMC can include your IMC's contact data from the DB on its own contact page at YOUR-IMC.indymedia.org, so you only need to keep one entry up to date and don't need to worry about editing CMS templates once it has been integrated.
• A user-friendly frontend for non-IMC people to contact their local IMC (also but not limited to volunteer.indymedia.org)
  The right people at your IMC will be contactable through either contact.indymedia.org or volunteer.indymedia.org, this should also integrate the world map from volunteer.indymedia.org
• A user-friendly frontend for moderated cross-posting to multiple IMCs' mailing lists (possible also to multiple IMCs web sites).
• Syndication of a listing of local IMCs RSS's (as already availabe at http://contact.indymedia.org/oml.php
• Syndication of a listing of local IMCs web link collections
• Syndication of a listing of local IMCs calendars
• Store server(s) information related to each IMCs site(s)
• Store server admin contact information for the various IMC servers
• Store IRC channel information for the various IMCs
• Store multiple contacts for each IMC: IMC process liaison, IMC database maintainer, private contact(s) (or mailing list), public contact(s) (or mailing list), tech contact(s) (or mailing list)
• Store general information for each IMC (web site URL, historical info (web site founded in ..., biggest event coverage so far...), ), spoken languages, CMS used, information on the reputation (read: imc-process approval as official IMC) within the Indymedia network...)
• Automatically send update reminders to private IMC contacts twice a year
• Automatically send information on non-updated IMCs to DB admins (mailing list?) twice a year
• Templating,custom CSS etc.
• Clean design

Code Design

Better i18n

• Full i18n of all strings.
• not all bundled in one file, but rather one per language
• we could borrow the system from another codebase ?

Seperation logic/presentation

• No mixture of logic & presentation anymore.
• Lay-out should be in templates.
• an easy to use base structure (base classes & stuff) that should make it easier to add extra functionality.

separation public & private part.

• A static part of the site for the public parts (like new_imc.php). maybe we can mirror that easily.
• dynamic admin part for things that need user authentication.

Security

• Security is an important issue as the DB is supposed to store the IMCs' private contact data
• Make sure, the email functions can not be used by spammers or trolls
• While security is important, accessibility is slightly more important.

-- PseudoPunk - 07 Jan 2004
to top