ToDo_Big_Items

#summary Future of packaging

jfesler 3/22/2013

= Introduction =

Right now, the project is pretty ad-hoc.

• Everyone checks out one or more copies of the svn repo
• Everyone builds from the repo
• Every build is compute expensive
  • Every site is unique
  • Every file is yuicompressed and precompressed for user consumption

What sucks about this

• Every update is a ton of CPU
• Every update requires a fair bit of trust or manual work
• Nothing is properly packaged or versioned, except for "svn co"

= What I want to do next =

All site specific configuration in a JSON file

• Perhaps like this: https://falling-sky.googlecode.com/svn/trunk/source/conceptual-future-config.js
• Any needed tools will need to read JSON
• JSON file can be served to the client

jfesler can produce releases

• as tarballs, or possibly as RPMs, etc
• OS native packages can handle prerequisites
  • Probably a distinct package for prereqs - so as to play nice with shared systems
• or even rsync.. which is convenient to the mirror operators.

Ideally, an update would be

• just a package update

And an initial install would be

• prereqs package install
• main content install
• mod_ip and php specific installs
• each of these could be done manually from svn as a fallback

Auto-updater

• Under what circumstances? Today just using DNS. What trust?
• Packages should perhaps be signed.

= Languages =

The other major issue is the config files for Apache are obscenely large. Can we..

• Detect user language, load the right files?
  • Allow switching languages with a cookie?
• Can a stub JS page do a script require of .jsgz?
• Ideally, Apache should not have the .gz logic
• Ideally, Apache should not do language detection

If this is not possible, can we at least distribute language mappings? If we can do this, it will allow us to add languagse later without mirrors having to update apache configs.

We may need to move text to .po format to benefit from existing tools for crowdsourcing.