AMO:v4/Planning/Goals

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

Goals

• New codename
  • Cuttlefish?
  • zamboni
  • samson
• 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
  • easy pagination, sorting, filtering
  • Worth it to separate db access from AMO? Have it use an API/service?
• As close to brainless escaping as possible for data in views
  • But be mindful of performance - the current escaping does too much
    • Escaping only when things are actually printed is as good as it gets
• 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
  • When there's an error, I want a full report of the stack leading up to the error plus the actual line where we have a problem.
• 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
• Templates should not be so verbose:
  • 7 characters, one of them meaningful: <?=$x?>
  • 7 characters, one of them meaningful: {{ x }}
    • So...maybe verbosity isn't the right metric. The second one still looks incredibly more appealing than the first. (jbalogh)

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