Things I want to get done before inevitably letting the project
bitrot:

* When we added Opus support, we did various checks to make
  sure that we don't try to stream Opus files w/ the HTML5
  jPlayer, since that doesn't support Opus.  We should probably
  have an "is_streamable" method on the Song class, though,
  rather than just checking for Opus all over the place.
  Something to think about...
* I think I'd like to include "slug"-like text in album URLs.
  Would put 'em after the ID, and they'd be optional (and
  completely ignored by the album view).  Would make sharing
  links a bit friendlier, though.  Make sure to include a
  maximum length, if I do it...
* Direct links to pages with django-tables2 (instead of just
  next/prev) -- the v2.4.1 that I'm using now while testing el8
  hosting has a nice solution for that built-in.  Will probably
  keep my own `X of Y` modifications in place, but pull those
  in.

Things which may or may not make that cut:

* Might be nice to actually spend some time to make it look
  better.  The sidebar's pretty ugly, etc.
* Should implement a max-number-of-results in search.  Probably
  only really an issue on Songs, maybe just use 500 like we do
  on the artist view page.
* Might be nice to have a mobile-optimized CSS
* Ability to specify subdirectories when doing add/update
  actions, to only process a subset of the library.
* http://reinout.vanrees.org/weblog/2014/05/19/context.html
  Basically, overriding get_context_data() in our views is
  wordy and not needed most of the time.  Use 'view.varname'
  in the template and it'll pull from the named var/func.
  No fussy context fiddling required!
* Use annotate() for some of our aggregate information on
  artist browse, for instance.
* Convert our three forms to actual django Forms.
* Might be nice to include an admin subcommand to clean the
  zip directory, which could be plugged into a cron rather than
  having to do your own.

Things which, if I'm being honest here, are likely to never
actually happen:

* Exordium can be slow, and it'd be nice to figure out if there
  are reasonable ways to speed it up, though it appears that in
  my case I'm primarily I/O bound.  The initial import of a
  42k-track library on my box takes about an hour, the majority
  of which is spent doing checksums of the files.  I've tested
  out using faster, less-secure checksum method (sha1sum, md5sum)
  and while those technically save us some time in CPU, it turns
  out that on my machine at least I'm primarily I/O bound while
  doing such large imports, and using the faster methods don't
  actually save any time.  Beyond the initial checksumming in the
  add process, there's still a good 15 minutes after that for
  database imports.  Relatedly, I'd put in some logic so that if
  an artist has more than 500 tracks, the track list isn't shown
  on the artist page, because performance was lousy there, too.
  It'd be nice to see if there's a good way to get that faster as
  well.  The good news is that outside of cases like that, it
  does seem to perform fine.  Adds/ updates are speedy enough for
  me, and in general the app is pretty responsive.
* More precise summary text for classical
  * "Composer, tracks 1-5, 8: foo", etc.
* Extra details on album song list (format, bitrate, etc)
  (something else for user prefs.  Will have to wait until
  I figure out a *reasonable* way to have dynamic column
  definitions in django-tables2.  I don't want to define
  a different class for each possibility.)
* Might be nice to support some artist groupings.
  ("Amanda Palmer and the Grand Theft Orchestra" albums
  should probably show up alongside "Amanda Palmer" albums,
  etc.  I assume this would be something manual-only from
  the admin area.  The "correct" thing to do might be to
  find a tag to use, instead, but I'm guessing that'd
  overly-complicate the backend, which I think I'd like
  to keep cleaner.  But it might be a monster anyway.)
* "Random albums" page?
* If deployed with WSGI configured for multiple processes,
  both user+global preferences only get applied properly
  on the process for which they were set.  Subsequent page
  loads may or may not come from the same process, so
  results can be inconsistent.  I'm not sure if there's a
  way around that or not - for now I've just dropped my
  number of processes down to 1.
* Maybe make "Various" a non-reserved artist name?  We
  could put in a big ol' random mess of characters for
  the name, and just rely on Artist.various to display
  it properly on the UI and all that.  That way if we
  ever have a band whose name really is "Various" we
  should be able to support it.  Would have to figure out
  some UI differences to differentiate, if so.  Maybe
  italics or something for the special artist?
* Theme support might be nice, and should be pretty
  trivial, though I doubt I'll take the time to figure
  it out.
* Could maybe apply some sorting while adding/updating so
  that updates appear in some kind of order rather than
  effectively randomly (would be especially nice for the
  initial bulk add(), so you'd have at least SOME indication
  of how much more time will be needed)
* Management subcommands to add/update the library
  (actually, this is more complicated than I'd considered
  initially, because the user running the add/update won't
  be the same as the user Django is running as, so 
  permission issues come into play.)
* Relatedly, the add/update stuff DOES sort of belong in
  something like celery instead, but I don't actually have
  any interest in implementing that on my host at the
  moment.
* Perhaps we should read genre from tags?
