[Subversion] / PEAK / TODO.txt  

View of /PEAK/TODO.txt

Parent Directory | Revision Log
Revision: 360 - (download)
Sun Mar 24 18:22:08 2002 UTC (22 years ago) by pje
File size: 4453 byte(s)
Added some notes on ideas for what might go into version 0.3.
Open Issues/To-Do Items

 Targeted for 0.2 Final Release

    API.Modules

      * Add tests for 'adviseModule()' API

    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.

    SEF

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


    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)

 

cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help