Open Issues/To-Do Items

Targeted for 0.2 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

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)