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

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

- Revisit getInterface() method of ComponentRegistration
  (i.e. UtilityRegistration) component. It can probably be just a simple
  attribute. The change should be trivial as well.

- 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 services 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.

- Restructure registration framework to use direct references rather
  than paths.

- 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/cleanup XML-RPC (?)

- Redo object hub (?)

- Catalogs (?)

- Finish cache framework:

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

- Write documentation on how to develop principal sources for the
  pluggable auth service.

- Local role definitions

- Local permission definitions

- 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 groups 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.

- 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, and

  - Including special source attributes that record locations
    of objects used in expressions.

- DTML2

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

- Local module service. This provides support for local imports as
  well as a place to manage security configuration for persistent
  modules.

  Provide support for within package access to persistent modules
  without the need to register them.

  * Change import mechanism:

    + only import from other modules and registrations in the same
      folder by default

    + importing from elsewhere should require explicit registration

  * Registrations that allow module security assertions

  * Name of the module within the folder must match the module name

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

- Finish WebDAV
  
  missing WebDAV verbs: PROPPATCH, 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.

- Schema fields

  Some kind of field that can contain objects that conform to a
  particular schema. And, widgets for this field.


- 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 menu service

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

- Finish persistent-module refactoring

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

- 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.

- Investigate "component specifications", that make more explicit the
  relationships among components.

  Add checking and better spelling of __used_for__.

- Replace the CacheName field/widget with a vocabulary
