TODO
====

More of a wishlist, really.

Planned features:

- Command-line option to specify a htpasswd file name for protection
    or maybe a randomly-generated password printed to stdout, so only the
    person running bin/zodbbrowser can access it
- Show persistent object attributes when hovering on a link?
- Figure out if it's possible to show a list of transactions at reasonable speed
    speed test: 66428 transactions in a 2 gb data.fs take ~12 seconds to
    iterate
    another 1.6 gb data.fs with 126735 transactions took 42 seconds
    a third 8 gb data.fs with 922737 transactions took 85 seconds (this is a
    newer, faster server: disk I/O at 100 megs/s instead of 8 megs/s of the
    old one)
    storage.iterator() always reads from the beginning of the file, so paging
    cannot be implemented efficiently with the current ZODB APIs.  Can we
    iterate once then cache all the data?  A million transaction records would
    take how much RAM?
    I'm afraid the only thing to do is to build a transaction index, for faster
    seeks.  Ugh.
- Help page in a javascripty-popup (lightbox-style)
- Finding backreferences
    could be very very expensive
- Breadcrumbs in browser session
    Consider: you're at /foo/bar/baz, you click on qux, but qux has no
    __parent__, now you're at /.../??? with no way of going back short of using
    the browser's back button.  So, maybe, store links (baz -> qux) in the
    browser session, and when the object has no path, show "you came here from:
    baz".

Optimization:

- Cache and reuse IObjectHistory adapters within request/transaction boundaries,
  this could give us a 2X speedup, according to
  https://bugs.launchpad.net/zodbbrowser/+bug/474334/comments/2

Refactorings:

- Standalone app: see if you can replace the zope publisher with something
  lightweight and modern (Pyramid?)

Tests:

- Complete test coverage
    - test ZEO ClientStorage integration (that ugly inspection hack)
    - unit tests for browser view code (will likely require refactoring)
    - tests for test infrastructure (things like html pretty-printing)
    - tests for javascript
- Buildbots for various python and zope versions
- Figure out how to shut up thread warnings in tests
    we don't actually leave any tests, zserver uses old thread api and
    threading gets confused; switching to something sane and WSGI instead
    of zserver would fix this.
- Implement ServerController.findUnusedPort
- Perhaps subclass testbrowser's Browser and add printXPath/printCSSPath
  methods to it directly.  I'm angling to make the ugly URL transformation
  in it somewhat less ugly, since the browser knows the URL and wouldn't need
  to hardcode a reference to TestsWithServer layer

