[Subversion] / PEAK / TODO.txt  

Diff of /PEAK/TODO.txt

Parent Directory | Revision Log

version 617, Thu Nov 7 00:12:14 2002 UTC version 752, Wed Nov 27 00:32:49 2002 UTC
Line 1 
Line 1 
 Open Issues/To-Do Items  Open Issues/To-Do Items
   
  Targeted for 0.5 Final Release   Targeted for 0.5 Alpha 1
   
     General      * Finish tutorial chapter 2
   
         * Update tutorial documentation  
   
         * Up-to-date and complete Persistence package      * Updated reference docstrings for 'peak.api', 'peak.binding',
         'peak.config', 'peak.exceptions', and 'peak.naming'.
   
         * Review possible cross-locational or "root" things like  
           'PropertyName' -- should these things move to the API?  
           Or where?  They're not 'util' things, certainly.  Perhaps  
           there should be a 'peak.core' module or package for things  
           that are foundational to all the packages?  
   
     peak.storage  
   
         - URLs and drivers for gadfly, Sybase, and postgres   Targeted for 0.5 Final Release (or sooner)
   
         - LDAP schema properties, SQL type mapping utilities  
   
         - Rack -> DM      General
   
         - "facade" DM base class(es)          * Tutorial complete through chapter 4
   
         - "query" DM base class(es)      peak.storage
   
         - unit tests for more complex object scenarios: references, thunks..?          - unit tests for more complex object scenarios: references, thunks..?
   
         - docstrings for reference          - lock management interfaces/API
   
     peak.binding  
   
         - object names/paths  
   
         - docstrings for reference          - docstrings for reference
   
     peak.model      peak.model
   
         - add support for lazy-loaded attributes  
   
         - clean up TW docstrings & interfaces          - clean up TW docstrings & interfaces
   
     peak.config  
   
         - docstrings for reference  
   
     peak.naming      peak.naming
   
         - clarify requirements re: initial context, and add SPI functions          - useful example "flat" naming context (e.g. like AppUtils.URLkeys)
           to initctx, so that that can be the right way to get such APIs  
           (e.g. getURLContext()).  
   
         - review context interfaces and URL hooks/hacks          - useful example hierarchical naming context (e.g. like JNDI's LDAP
             context or filesystem context)
   
         - docstrings for reference          - rework smtp: to return a factory object that supports open().
             Also think about whether smtp should move elsewhere. Maybe
             there should be peak.network or peak.internet for things like
             smtp, ftp, etc contexts?
   
     peak.running      peak.running
   
         - more docs for new 'cluster' tools          - more docs for new 'cluster' tools
   
         - create a basic LogFile logging provider          - make 'cluster' parser complain about things that would cause
             the clusterit tools to choke or barf on the file, or which would
         - unit tests for daemons?            produce ambiguous or unintended results.
   
         - simple daemons comparable to those in MetaDaemon?          - finish misc tasks on peak.running.logs's TODO list
   
         - docstrings for reference          - simple daemons comparable to those in MetaDaemon
   
     peak.util          - unit tests for daemons
   
         - docstrings for reference          - docstrings for reference
   
         - more unit tests?      peak.config
   
   
           - "Rule"-oriented configuration files (section specifies component
             rather than property name prefix), so that daemons and other simple
             apps can be fully configured and run via a config file.
   
       peak.util
   
           - docstrings for reference
   
           - more unit tests?
   
   
   
Line 135 
Line 123 
   
   peak.model    peak.model
   
     * Review other-end-notification protocols in the light of managed storage  
       models (e.g. database Records using virtual sequence objects as fields)  
   
     * Marshalling interface in Services; implementations for Enumeration, etc.      * Marshalling interface in Services; implementations for Enumeration, etc.
   
     * More S-E-F metadata: features, subclasses, svc.<->class, nested services      * More S-E-F metadata: features, subclasses, svc.<->class, nested services
Line 148 
Line 133 
   
     * "Indexed" version of in-memory model?      * "Indexed" version of in-memory model?
   
     * "Persistent" StructuralModel (indexes w/BTrees?  Catalog?)  
   
   
     Queries      Queries
   
Line 174 
Line 157 
   
   
   
   
   
   
   
   
   peak.metamodels.uml    peak.metamodels.uml
   
     * Need to write an MMX or XMI -> Python generator, and hook it back up into      * Need to write an MMX or XMI -> Python generator, and hook it back up into
Line 219 
Line 207 
   
     * Re-org to self-contain all XMI stuff inside an _XMI sub-component/service      * Re-org to self-contain all XMI stuff inside an _XMI sub-component/service
   
     * Refactoring to pure S-E-F model using Persistence  
   
     * Document version of standard used      * Document version of standard used
   
     * Metamodel identity/version checking      * Metamodel identity/version checking


Generate output suitable for use with a patch program
Legend:
Removed from v.617  
changed lines
  Added in v.752

cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help