View of /PEAK/TODO.txt

Parent Directory

Revision Log

Added warnings for detectable module-level modifications of mutables
in modules which are used for inheritances or advice.  Added an API
function, 'configure(object, attr1=val, attr2=val,...)' to safely
set attributes of mutables that might have been defined in a derived
module.  Also, misc. updates to TODO.

Open Issues/To-Do Items

 Targeted for 0.2 Final Release

    API.Modules

      * Add tests for 'adviseModule()' API

      * Add checks and warnings for ambiguous re-assignments of global
        variables and class attributes.

    Database

      * Create test suite to check proper transactional functioning, cache
        consistency, queueing behavior, and typemap management.

      * Update Interfaces to reflect current API, and document internals

    General

      * Update tutorial documentation

 Ideas for 0.3 Release

    Dispatching

      * Virtual features to implement retrieving the other end of a
        relationship from another Specialist, and to handle rebinding to
        records after record invalidation.

    SEF

      * Move binding tools to a seperate module (e.g. 'TW.CIS' for "Component
        Integration Services").

      * Persistent SEF module, with Base.__getstate__ supporting omission
        of Once attributes, and DynamicBinding setting _p_changed on
        instantiation.

      * A way to generate Z3 Interfaces from Feature-based specifications?

    Database

      * Rack-like object to do persistent storage of Elements?

      * Support for field transformations and default values at RecordType
        level, e.g marshalling and type conversion.  This would be
        especially useful for LDAP.

      * Support for sending and receiving remote cache invalidation
        messages between RecordManagers.

    General

      * Profiling and performance tuning of module inheritance and other
        core features of API and SEF.



 Future Releases

  Simulator/Module Inheritance

    * Need a strategy for handling "del" operations; they are currently
      untrapped.  This might be okay under most circumstances, but need to
      consider edge cases.

    * 'makeClass()' should probably become part of the core API, where
      it can be used to resolve __metaclass__ conflicts during the first
      pass of importing a module (prior to running 'setupModule()')


  Documentation/Tests/General

    * Create tutorials/examples based on actual uses

    * Include dependencies in packaging?  Need to ask copyright owners first.





  SEF

    * 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

    * Implement WarpCORE-oriented structural model, w/Querying support

    InMemory

      * "Indexed" version

      * "WeakRefs" version (no acquisition, use w/Python 2.1 weakrefs)

      * "Circular" version (suitable for use w/2.1 GC or Jython)

      * "Persistent" StructuralModel (indexes w/BTrees?  Catalog?)

    Queries

       * Refactor to use interfaces, if appropriate

       * Incorporate into AbstractModel?

         - Pros:

           * Queries always available

           * Each StructuralModel implementation can easily include its own
             performance-tuned version of the basic items.

         - Con: default implementation doesn't perform well on large datasets

       * How much of framework needs extensibility?  Should the predicate
         classes be placed in the StructuralModel's namespace so that predicates
         have their meaning assigned by the StructuralModel implementation?


  UML

    * Need to write an MMX or XMI -> Python generator, and hook it back up into
      the UML package, since we're right now relying on a module generated
      by code that depends on stuff which is going away.

    * Helper methods in Elements & Services for marshalling, common queries, etc.

    * Generator framework

      - Tagged values in stereotypes vs. main values?

      - Should tagged values be copied directly into templates?  Treated as
        Python expressions?

      - Should Services be generated using an Element class' "static"
        (class-scope) methods/attributes?

        - Are association-ends scoped?

        - Would it be better to seperate them?

      - What determines whether an implemented Service actually stores objects
        or delegates this to its subclass services?

    * Simple Zope product demo (upload XMI, then browse the model via the web)

    * Reporting mixins?  Graphviz visualization?













  XMI

    * Re-org to self-contain all XMI stuff inside an _XMI sub-component/service

    * Refactoring to pure S-E-F model

    * 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)