============================================================
Things to do After the next release (in no particular order) 
============================================================

- Issue 372: WidgetInputError.doc is broken

- Support for iterable sources

- Issue 296: missing display widgets

- Issue 316: Zope3 test.py truncates path with dir=

- Issue 390: Request body and bodyFile are bogus, and have a misleading
  documentation. (This issue has been addressed in the Twisted-Integration
  branch, which  will be merged to the trunk after the 3.1 split and thus be
  in for 3.2.)

- Finish new Message support (Philipp)

- Write tests for the Dublin Core Structured Value support, especially errors
  and createMapping(). See zope.app.dublincore.dcsv.

- The mapping from file endings to mime types is handled through configuration
  in Zope 2 now.  Perhaps we can do the same for Zope 3.

- When converting a possible site to a site, prompt the user for utilities that
  should be added right away. See zope/app/site/browser/__init__.py

- http://dev.zope.org/Zope3/TALESPathExpressionAdapters

- I think the session api needs a little more work.  Among other
  things, it needs to get tied into zpt.

- http://dev.zope.org/Zope3/NoMoreSchemaBinding

- http://dev.zope.org/Zope3/ActionPlans

- Persistent interfaces cannot be provided as providedBy or implementedBy
  interfaces anymore. This functionality was broken during some interface and
  adapter refactorings. 

- http://dev.zope.org/Zope3/CleanupOfSchemaAndWidgets

  Only Schema Arithmetic is left from this proposal.

- Partial adapters

  http://dev.zope.org/Zope3/PartialAdapters

  Maybe we can live without these.

- Merge zope.conf and zdaemon.conf. This is a Fred Drake task. :)

- http://dev.zope.org/Zope3/LifeCycleEvents

- Permission rationalization

  Absent deep thinking, then create a set of fine-grained permission
  and a default permission redefinition that makes them course grained

- Implement graceful shutdown and restart a la Zope 2. We have to add a bit of
  code to the server to support this, but it should not be too hard, since we
  have an implementation in Zope 2.

- http://dev.zope.org/Zope3/ZCMLEnhancements

  Implement disable directive.

- Local event subscriptions

- Finish cache framework:

  http://dev.zope.org/Zope3/Zope.App.Caching

- Untrusted modules.  Also implement a way of specifying policies for
  trusted and untrusted modules.  At a minimum:

  * Say globally whether or not modules are trusted or
    untrusted.

  * Say globally whether modules are editable through the web.

  A slight variation on this is to have two kinds of modules and say
  under what circumstances they are editable through the web (or
  otherwise).

- File-system synchronization

  * Client command-line tool w HTTP-based interface to server that
    provided CVS-like interface and features. Including:

    + checkout and commit

    + update including merge and offline version

    + diff and offline diff

  * Refine the adapter protocol or implementation to leverage the
    file-system representation protocol.

  * Maybe leverage adaptable storage ideas to assure losslessness.

  * In common case where extra data are simple values, store extra
    data in the entries file to simplify representation and updates.
    Maybe do something similar w annotations.

  * Maybe do some more xmlpickle refinement with an eye toward
    improving the usability of simple dictionary pickles.

  * export and import as a special case

  * Improve some common data file formats (e.g. simplify entries
    file).

  * Work out security details

- Software bundles.

- Local/persistent modules:

  * Output to stderr/stdout should be captured, saved to be viewed
    after import

- Support for permission categories in the security model. No
  one has been interested in working on this and, at this point,
  there are too many other things to do. We *are* committed to
  adding this eventually assuming that it becomes necessary due
  to a large number of permissions.

- Support for executable identity / code ownership.
  I'm not positive that anybody actually wants this. :)

- Better ZPT debugging support

  It's sometimes hard to tell where the pieces that make up a
  page come from.  We'll investigate:

  - Leaving TAL and METAL markup in the output (this is done already), and

  - Including special source attributes that record locations
    of objects used in expressions (this is partially done -- you can
    add HTML comments, but there were also plans to add XML attributes that
    are more accessible from Javascript etc.).

- DTML2

  DTML2 is a version of DTML that uses TALES *instead* of the
  traditional DTML namespace stack and expression mechanisms.

- Fix a number of bugs and rough edges in page folders

- Finish WebDAV
  
  missing WebDAV verbs: MOVE, COPY, DELETE, LOCK and UNLOCK

- Python scripts

  What form should these take? Should they be like Zope 2 Python
  scripts? or should they by like Python modules.

- Supply a generic property mechanism?

  In Zope 2, folders and many other objects could have arbitrary
  properties.  This was very useful to storing little bits of content.
  What form should this take in Zope 3?

- UI

  * Add nested menus.

- Revisit and, to degree necessary, implement:

  http://dev.zope.org/Zope3/TTWDevelopmentScopeForZopeX310

  I think we probably need to scale back out expectations for the code
  to:

  - Persistent modules

  - Local browser menus

  - Views

  - Adapters

  - Management of database-based services and utilities.

  - File-system sync

  Configuration browsing and management.

  IOW, clean up what we already have.

  We probably need to defer:

  - Bundles

  - New content types

  - Local factories

  Current efforts could continue to be pursued as add-on items.

- Redo form machinery

  The existing form implementation is neither as clean or as flexible
  as it should be, but it might be OK for the first release.

- Reimplement or port Evan's ZPT adapter work.
