Open Issues/To-Do Items

 Targeted for 0.5 Final Release

    General

      * Update tutorial documentation

    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



 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


  Messaging/ObjectSpaces

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


  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

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

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

    * "Indexed" version of in-memory model?

    * "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?


  peak.metamodels.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)















  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)