[Subversion] / PEAK / TODO.txt  

Diff of /PEAK/TODO.txt

Parent Directory | Revision Log

version 961, Thu Apr 3 22:39:50 2003 UTC version 1108, Sat May 10 21:29:49 2003 UTC
Line 1 
Line 1 
 Open Issues/To-Do Items  Open Issues/To-Do Items
   
  Targeted for 0.5 Alpha 1   Targeted for 0.5 Alpha 2
   
       * ZConfig Integration
   
         - A 'config.ZConfig' module that provides "PEAK-aware" versions of ZConfig
           services (e.g. it will use 'peak.naming' to resolve URLs)
   
         - App startup tools based on ZConfig files.
   
         - Sample 'AdaptiveTask' classes that perform the same functions as those in
           the MetaDaemon package, with a ZConfig schema to run them in a daemon-like
           application.
   
     * Fix issue w/reading XMI 1.1 files where metamodel has nested packages      * Fix issue w/reading XMI 1.1 files where metamodel has nested packages
   
     * Document interface expected of "active descriptors" and their complements      * Generate UML 1.4 and 1.5 and CWM 1.0 and 1.1, and add them to the
       (e.g. __class_provides__), refactoring for cleanliness as needed.        'setup.py' package lists.
   
     * Refactor "Pythonic" UML 1.3 extensions so they're usable for most      * Add reference docs for 'peak.interface'
       MOF-aligned metamodels (e.g. all UML and CWM versions)  
   
     * Remove deprecated items from peak.model: Feature, Reference, Package,      * Create tutorial section for 'peak.interface'
       Model, Namespace, DataType, etc.  
   
     * Get XMI writing in place, w/transaction support   Targeted for 0.5 Beta 1
   
     * 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'.
   
     * Finish tutorial chapter 2 (?)      * Finish tutorial chapter 2 (?)
   
  Targeted for 0.5 Alpha 2      * Web publishing framework sufficient to deploy page-based or object-
         published apps
   
       * Get XMI writing in place, w/transaction support
   
     * On-the-fly class combination (think "runtime module inheritance",      * On-the-fly class combination (think "runtime module inheritance",
       without the modules) for DMs.        without the modules) for DMs.
   
     * ZConfig support, probably in the form of generating ZConfig schemas  
       from 'peak.model' or MOF models, but maybe in the form of 'fromZConfig'  
       constructor methods as well.  
   
     * 'peak.running' refactorings: use standard 'logging' module's log levels,  
        add 'logging' distro to 'peak.util' for 2.2 backward compatibility,  
        make daemons based on 'peak.model' (or at least define ZConfig schemas),  
        and possibly adjust cluster stuff to work off ZConfig primary and  
        generate clustertools file(s).  App startup tools based on ZConfig and  
        PEAK-style .ini files.  
   
     * 'peak.naming' refactorings: 'peak.model'-based syntax utilities for  
        creating address syntaxes.  
   
  Targeted for 0.5 Final Release (or sooner)   Targeted for 0.5 Final Release (or sooner)
   
Line 127 
Line 127 
   relevant as written, they are being kept on this list as placeholders for    relevant as written, they are being kept on this list as placeholders for
   ideas or problem areas that may need to be re-considered in future.)    ideas or problem areas that may need to be re-considered in future.)
   
     Miscellaneous
   
       * Functional tests that access "real" databases, LDAP, etc.
   
   Simulator/Module Inheritance    Simulator/Module Inheritance
   
       * Allow 'declareModule()' to bootstrap non-existent modules; this might
         let us create "virtual packages" made by assembling other packages and
         modules.
   
     * Need a strategy for handling "del" operations; they are currently      * Need a strategy for handling "del" operations; they are currently
       untrapped.  This might be okay under most circumstances, but need to        untrapped.  This might be okay under most circumstances, but need to
       consider edge cases.        consider edge cases.
Line 142 
Line 149 
   Messaging/ObjectSpaces    Messaging/ObjectSpaces
   
     * Support for sending and receiving remote cache invalidation      * Support for sending and receiving remote cache invalidation
       messages between RecordManagers.        messages between DataManagers.
   
   
   
   
   
   
   
   
   
   
Line 228 
Line 228 
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   


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

cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help