[Zope3-checkins] CVS: Zope3/doc - ROADMAP.txt:1.9 TODO.txt:1.13
TODOLATER.txt:1.4
Jim Fulton
jim at zope.com
Tue Feb 10 20:17:37 EST 2004
Update of /cvs-repository/Zope3/doc
In directory cvs.zope.org:/tmp/cvs-serv13216/doc
Modified Files:
ROADMAP.txt TODO.txt TODOLATER.txt
Log Message:
Updated roadmap, separating tasks into TODO and TODOLATER.
=== Zope3/doc/ROADMAP.txt 1.8 => 1.9 ===
--- Zope3/doc/ROADMAP.txt:1.8 Thu Feb 5 19:49:19 2004
+++ Zope3/doc/ROADMAP.txt Tue Feb 10 20:17:37 2004
@@ -4,176 +4,10 @@
the compliment of CHANGES.txt. Over time, entries from this file
will migrate to CHANGES.txt and then to HISTORY.txt.
- Zope X3 1.0
+ Zope X3 1.0 (Zope X3.0.0?)
- Foundational work
-
- - ZODB 3.3 in Zope 3
-
- See: http://zope.org/Wikis/ZODB/PersistentCodeImplementationPlan
-
- - Persistent interfaces
-
- These were broken (I think) by recent interface and adapter
- refactoring.
-
- - Redo event service
-
- o Simplify publication/registration framework
-
- o Subscribe directly, rather than by path
-
- - Maybe: http://dev.zope.org/Zope3/FixedDefaultComponentLookup
-
- This is extremely controversial
-
-
- - Partial adapters
-
- http://dev.zope.org/Zope3/PartialAdapters
-
- - Fix up presentation-component franeworks to use presentation
- components registered by interface.
-
- - 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 object hub
-
- - Minor refactoring of security context
-
- http://dev.zope.org/Zope3/UnificationOfRequestsAndSecurityContextsThroughUse
-
- - Redo menu service
-
- http://dev.zope.org/Zope3/AdaptersForMenuItems
- http://dev.zope.org/Zope3/PartialAdapters
-
- - Maybe rethink annotations (maybe not ;)
-
- - Finish persistent-module refactoring
-
- http://dev.zope.org/Zope3/ModulesAreGlobal
-
- - Minor refactoring of adapter service to make it fast to find
- all names for adapters from/to a given interface
-
- - Redo utility service
-
- - Restructure registration framework to use direct references rather
- than paths.
-
- - Finish location-relevent event work to handle
-
- Specifically, handling events on containers.
-
- See:
- http://dev.zope.org/Zope3/LocationRelatedEvents
-
- - Finish http://dev.zope.org/Zope3/ComponentArchitectureSimplification
-
- What remains is the section "Utilities everywhere".
-
- - Language negotiation
-
- - Translation (?) Note that if these were utilities, you could
- have independent utilities prt domain
-
- - Caching (Naveen is working on this)
-
- - SQL Database connections (Mostly done, but Madhavi and Mohan
- working on new UI).
-
- - DAV schema
-
- - Interface (Murthy and Suresh are working on these)
-
- - Vocabularies (warn Gary and Casey :)
-
- - Roles
-
- - Permissions
-
- - Session data managers
-
- - Workflow definitions
-
- - Rendered source types
-
- - Interpreter types
-
- - Mail
-
- - HubIDs
-
- We need to think about the UI for managing these. For example, a
- site manager is likely to want to "Manage Database
- Connections". They probably don't want to think of these in terms of
- utilities.
-
- - Maybe 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.
-
- - Finish DAV?
-
- - Finish/cleanup XML-RPC (?)
-
- - Clean up zope.app by moving many things out
-
- Scriptor support
-
- What do we need for 1.0?
-
- I think we need to at least port (or reimplement) Evan's ZPT
- adapter work.
-
- Finishing
-
- - Fix bugs
-
- - Fix UI
-
- - Provide Zope-2 style installation, configuration and process
- management.
+ See the to-do list: TODO.txt.
Later releases
- Zope X3.0
-
- See the to-do list: TODO.txt.
-
- After Zope X3.0
-
- See the list of things to do later: TODOLATER.txt.
+ See the list of things to do later: TODOLATER.txt.
=== Zope3/doc/TODO.txt 1.12 => 1.13 ===
--- Zope3/doc/TODO.txt:1.12 Mon Nov 24 13:00:23 2003
+++ Zope3/doc/TODO.txt Tue Feb 10 20:17:37 2004
@@ -1,108 +1,104 @@
-This file contains short descriptions of projects or tasks that need
-to get done by the first Zope X3 beta release.
+============================================================
+Things to do for the next release (in no particular order)
+============================================================
-The order that items are listed here is not significant.
+- Zope-2 style installation, configuration and process management.
-- Finish cache framework:
+- ZODB 3.3 in Zope 3
- http://dev.zope.org/Zope3/Zope.App.Caching
+ See: http://zope.org/Wikis/ZODB/PersistentCodeImplementationPlan
-- Write documentation on how to develop principal sources for the
- pluggable auth service.
+- Persistent interfaces
-- Redo local Role service to use configurations
+ These were broken (I think) by recent interface and adapter
+ refactoring.
-- Implement a local permission service (using configurations)
+- Reorganize software into a much flatter package structure.
-- Rethink the organization of the security software to reflect the
- fact that people will likely plug in different grant and ownership
- systems for different security policies.
+- Redo event service
- * Document the relationship between the security policy and the
- grants
+ o Simplify publication/registration framework
-- Untrusted modules. Also implement a way of specifying policies for
- trusted and untrusted modules. At a minimum:
+ o Subscribe directly, rather than by path
- * Say globally whether or not modules are trusted or
- untrusted.
+- Change the way components are looked up locally:
- * Say globally whether modules are editable through the web.
+ http://dev.zope.org/Zope3/FixedDefaultComponentLookup
- 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).
+- Partial adapters
-- File-system synchronization
+ http://dev.zope.org/Zope3/PartialAdapters
- * Client command-line tool w HTTP-based interface to server that
- provided CVS-like interface and features. Including:
+- Minor refactoring of security context
- + checkout and commit
+ http://dev.zope.org/Zope3/UnificationOfRequestsAndSecurityContextsThroughUse
- + update including merge and offline version
+- Fix up presentation-component franeworks to use presentation
+ components registered by interface.
- + diff and offline diff
+- Redo object hub (?)
- * Refine the adapter protocol or implementation to leverage the
- file-system representation protocol.
+- Catalogs (?)
- * Maybe leverage adaptable storage ideas to assure losslessness.
+- Minor refactoring of adapter service to make it fast to find
+ all names for adapters from/to a given interface
- * 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.
+- Redo utility service
- * Maybe do some more xmlpickle refinement with an eye toward
- improving the usability of simple dictionary pickles.
+- Restructure registration framework to use direct references rather
+ than paths.
- * export and import as a special case
+- Finish location-relevent event work;
+ specifically, handling events on containers.
- * Improve some common data file formats (e.g. simplify entries
- file).
+ See:
+ http://dev.zope.org/Zope3/LocationRelatedEvents
- * Work out security details
+- Finish http://dev.zope.org/Zope3/ComponentArchitectureSimplification
- Guido is working on this.
+ What remains is the section "Utilities everywhere".
-- Software bundles.
+ - Language negotiation
-- ZCML directive for layers and corresponding checks that a resource
- is registered in a registered layer
+ - Translation (?) Note that if these were utilities, you could
+ have independent utilities prt domain
- * Typos can cause new layers to be defined unintentionally
+ - Caching (Naveen is working on this)
-- Local/persistent modules:
+ - SQL Database connections (Mostly done, but Madhavi and Mohan
+ working on new UI).
- * Output to stderr/stdout should be captured, saved to be viewed
- after import
+ - DAV schema
-- ZCML directives for module security
+ - Interface (Murthy and Suresh are working on these)
- * Fix the ++module++ namespace to honor security assertions; instead
- of ++module++pkg.mod.Thing, we should use ++module++pkg.mod/Thing
+ - Vocabularies (warn Gary and Casey :)
-- Local module service. This provides support for local imports as
- well as a place to manage security configuration for persistent
- modules.
+ - Roles
- Provide support for within package access to persistent modules
- without the need to register them.
+ - Permissions
- * Change import mechanism:
+ - Session data managers
- + only import from other modules and registrations in the same
- folder by default
+ - Workflow definitions
- + importing from elsewhere should require explicit registration
+ - Rendered source types
- * Registrations that allow module security assertions
+ - Interpreter types
- * Name of the module within the folder must match the module name
+ - Mail
+
+ - HubIDs
+
+- Implement tools:
+
+ http://dev.zope.org/Zope3/TheBrowserToolDirective
+
+- Finish/cleanup XML-RPC (?)
- Rework undo
- Simplify the undo model. To kinds of undo:
+ Simplify the undo model. Two kinds of undo:
* Undo my changes
@@ -114,33 +110,6 @@
Make sure we handle multiple undos properly.
-- Implement interface types, and thus content types.
-
- * Categories? (Not inheritable.)
-
-- Local Interface service
-
- This service should support:
-
- * Local interface registration
-
- * Interface browsing
-
- + by type
-
- By default, you'll browse content types. IOW, the default usage
- will be as a content-type service.
-
- * Central point for configuration by content type.
-
- You can walk up to the interface service and see the content types
- defined for the system. You can select a type and see all of the
- configuration for that type.
-
-- Fix a number of bugs and rough edges in page folders
-
-- Finish WebDAV
-
- Finish "process control", specifically shutting down and restarting
via the web. The main issue here is plumbing. How to get the
signal from the UI to the server logic. The way to do this is via
@@ -148,11 +117,6 @@
and code in the server should be subscribed. Care needs to be taken
to assure that only privileged users can generate these events.
-- Help System?
-
- There is one, but I don't know what state it's in or how to write
- help for it.
-
- Broken-object support
When an object cannot be unpickled because it's class can't be found,
@@ -161,31 +125,8 @@
See http://collector.zope.org/Zope3-dev/109
This requires a hook in the ZODB that Zope can override.
-- 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
- * Get rid of "common tasks".
-
- * Make the add menu a pull-down menu
-
- * Add nested menus.
-
- * Make it easier to get to the error logging service.
-
- * Get the html titles a lot righter than they are now.
-
-- Schema fields
-
- Some kind of field that can contain objects that conform to a
- particular schema. And, widgets for this field.
+ * Rename "common tasks" to "Add". Eventually (after next release)
+ replace with a pull-down add menu
=== Zope3/doc/TODOLATER.txt 1.3 => 1.4 ===
--- Zope3/doc/TODOLATER.txt:1.3 Mon Jul 14 09:31:16 2003
+++ Zope3/doc/TODOLATER.txt Tue Feb 10 20:17:37 2004
@@ -1,4 +1,72 @@
-Things to do After Zope X3.0
+============================================================
+Things to do After the next release (in no particular order)
+============================================================
+
+- Finish cache framework:
+
+ http://dev.zope.org/Zope3/Zope.App.Caching
+
+- Write documentation on how to develop principal sources for the
+ pluggable auth service.
+
+- Reimplement roles as utilities
+
+- Local roles
+
+- Reimplement permissions as utilities
+
+- Local permissions
+
+- 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
+
+ Guido is working on this.
+
+- 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
@@ -28,3 +96,101 @@
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
+
+- Help System?
+
+ There is one, but I don't know what state it's in or how to write
+ help for it.
+
+- 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.
More information about the Zope3-Checkins
mailing list