AMO:v4/Planning

AMO:v4 » Planning

Just throwing out ideas for now. Please fill in your thoughts, we can focus this document down later.

Goals

• Useful DBAL: Object based, smart caching/expiration, smart master/slave, smart escaping
  • ...doesn't pull too much data unless you ask for it
  • composable queries
• As close to brainless escaping as possible for data in views
• Unit tests that don't run out of memory and can be monitored. Expanded test data.
  • ...and that aren't a hassle to write and don't kill you inside. To me, that means powerful introspection and mocking so I can look at the running code at any point in the response cycle.
• Continuous integration with automatic(ish) production deployment (database stuff will be harder...)
• Form validation with or without models.
• Easy ajax or rest. Possible to separate content/data from html markup in a view.
• Transparent unicode support
  • Doesn't all of AMO use UTF-8? --wenzel 17:39, 5 October 2009 (UTC)
  • Not when we forget to use mb_* strings; anyways, I was including unicode more to make sure we think about it
• Easy debugging/development
• Logging
• Message queue / offline work queue
  • Sometimes you want to do things that aren't part of a web request. That should not be impossible.
  • See also: gearman, rabbitmq

How are we going to get there?

• Try to replace one major section / block of functionality at a time, incrementally.
  • Wholesale rewrites tend toward disaster.
• Make a more poweful API and just build off that?
  • Would that fix the broken escaping, testing, querying, & so on?
  • Could gradually convert bits of AMO to APIs, build new frontends, then replace the APIs

• Potential framework changes:
  • Any framework change will require some substantial planning regarding operating while migrating.
  • Could upgrade to cakephp 1.2. I fear the dev team will riot.
    • Rabble rabble!
  • Could switch to kohana
  • Could switch to django