AMO:v4/Planning/Goals

From MozillaWiki
Jump to: navigation, search

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

Goals

  • New codename
  • 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