Pyramid TODOs
=============

Nice-to-Have
------------

- Have ``remember`` and ``forget`` actually set headers on the response using
  a response callback (and return the empty list)?

- Add narrative docs for wsgiapp and wsgiapp2.

- Better "Extending" chapter.

- Flesh out "Paste" narrative docs chapter.

- Basic WSGI documentation (pipeline / app / server).

- Change docs about creating a venusian decorator to not use ZCA.

- Try to better explain the relationship between a renderer and a template in
  the templates chapter and elsewhere.  Scan the documentation for reference
  to a renderer as *only* view configuration (it's a larger concept now).

- Add better docs about what-to-do-when-behind-a-proxy: paste.urlmap ("/foo =
  app1" and "domain app1.localhost = app1"), ProxyPreserveHost and the nginx
  equivalent, preserving HTTPS URLs.

- _fix_registry should dictify the registry being fixed.

- Make "localizer" a property of request (instead of requiring
  "get_localizer(request)"?

- Alias the stupid long default session factory name.

- Debug option to print view matching decision (e.g. debug_viewlookup or so).

- Non-bwcompat use of threadlocals that need to be documented or ameliorated:

  security.principals_allowed_by_permission

  resource.OverrideProvider._get_overrides: can't credibly be removed,
  because it stores an overrideprovider as a module-scope global.

  traversal.traverse: this API is a stepchild, and needs to be changed.

  Configurator.add_translation_dirs: not passed any context but a message,
  can't credibly be removed.

- Deprecate pyramid.security.view_execution_permitted (it only works for
  traversal).

- Create a function which performs a recursive request.

- Create a ``render_view`` that works by using config.derive_view against an
  existing view callable instead of querying the registry (some sort of API
  for rendering a view callable object to a response from within another view
  callable). Possible idea: have config.add_view mark up the
  function/method/class like @view_config does, then use the attached info to
  derive a view callable whenever called via some API.

- Provide a ``has_view`` function.

- Update App engine chapter with less creaky directions.

- Introspection features (whatever is needed by Alan/ptah).


Future
------

- 1.3: Remove ``pyramid.renderers.renderer_from_name`` (deprecated).

- 1.3: Kill off ``bfg.routes`` envvars in router.

- 1.3: Michael's route group work

- 1.3: Add a default-view-config-params decorator that can be applied to a
  class which names defaults for method-based view_config decorator options.

- 1.3: use zope.registry rather than zope.component.

- 1.4: Remove ``chameleon_text`` / ``chameleon_zpt`` deprecated functions
  (render_*)

- 1.4: Remove ``pyramid.configuration.ConfigurationError`` (deprecated).

- 1.4: Remove ``pyramid.paster.PyramidTemplate`` (deprecated).

- 1.4: Remove ``pyramid.settings.get_settings`` (deprecated).

- 1.5: Remove all deprecated ``pyramid.testing`` functions.

- 1.5: turn ``pyramid.settings.Settings`` into a function that returns the
  original dict (after ``__getattr__`` deprecation period, it was deprecated
  in 1.2).

- 1.5: Remove ``pyramid.requests.DeprecatedRequestMethodsMixin``.

Probably Bad Ideas
------------------

- Add functionality that mocks the behavior of ``repoze.browserid``.

- Consider implementing the API outlined in
  http://plope.com/pyramid_auth_design_api_postmortem, phasing out the
  current auth-n-auth abstractions in a backwards compatible way.

- Maybe add ``add_renderer_globals`` method to Configurator.

- Supply ``X-Vhm-Host`` support (probably better to do what paste#prefix
  middleware does).