[Subversion] / PEAK / TODO.txt  

Diff of /PEAK/TODO.txt

Parent Directory | Revision Log

version 652, Sat Nov 9 00:05:52 2002 UTC version 860, Fri Feb 7 23:55:35 2003 UTC
Line 2 
Line 2 
   
  Targeted for 0.5 Alpha 1   Targeted for 0.5 Alpha 1
   
     * Object name/path support in 'peak.binding'      * Finish tutorial chapter 2
   
     * 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?  
   
     * Updated reference docstrings for 'peak.api', 'peak.binding',      * Updated reference docstrings for 'peak.api', 'peak.binding',
       'peak.config', 'peak.exceptions', and 'peak.naming'.        'peak.config', 'peak.exceptions', and 'peak.naming'.
   
     * Additional content for the tutorial's chapter on binding  
   
  Targeted for 0.5 Final Release   Targeted for 0.5 Final Release (or sooner)
   
     General  
   
         * Update tutorial documentation      General
   
         * Up-to-date and complete Persistence package          * Tutorial complete through chapter 4
   
     peak.storage      peak.storage
   
         - URL+driver for postgres          - unit tests for more complex object scenarios: references, thunks..?
   
         - LDAP schema properties, SQL type mapping utilities  
   
         - Rack -> DM          - lock management interfaces/API
   
         - "facade" DM base class(es)          - docstrings for reference
   
         - "query" DM base class(es)      peak.model
   
         - unit tests for more complex object scenarios: references, thunks..?          - clean up TW docstrings & interfaces
   
         - docstrings for reference      peak.naming
   
     peak.model          - useful example "flat" naming context (e.g. like AppUtils.URLkeys)
   
         - add support for lazy-loaded attributes          - useful example hierarchical naming context (e.g. like JNDI's LDAP
             context or filesystem context)
   
         - clean up TW docstrings & interfaces          - 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 123 
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.  
   
     * More S-E-F metadata: features, subclasses, svc.<->class, nested services  
   
     * A way to generate Z3 Interfaces from Feature-based specifications?      * A way to generate Z3 Interfaces from Feature-based specifications?
   
     * Implement WarpCORE-oriented structural model, w/Querying support      * Implement WarpCORE-oriented structural model, w/Querying support
   
     * "Indexed" version of in-memory model?      * "Indexed" version of in-memory model?
   
     * "Persistent" StructuralModel (indexes w/BTrees?  Catalog?)  
   
   
     Queries      Queries
   
Line 162 
Line 153 
   
   
   
   
   
   
   
   
   
   
   
   
   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 191 
Line 191 
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   peak.metamodels.xmi  
   
     * 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  
   
     * Metamodel identity/version checking  
   
     * XMI.Writing  
   
     * Strict parsing and/or diagnostics on files that don't match the metamodel?  
   
     * UUID/GUID support  
   
     * Support for advanced references, external references?  
   
     * XML Namespaces (do any current XMI tools need this?  Which spec version  
       requires this?)  
   
     * DOM StructuralModel (so files can be edited without affecting vendor XMI  
       extensions)  
   
   


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

cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help