View of /PEAK/TODO.txt
Parent Directory
| Revision Log
Revision:
356 -
(
download)
Sat Mar 23 23:35:28 2002 UTC (22 years, 1 month ago) by
pje
File size: 4101 byte(s)
Moved TODO.txt out of the docs directory so HappyDoc will make an HTML file
for it in the reference docs.
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
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()')
* Test "advice" functionality, add more docs.
Database
* Create configurable caching mixins/plugins for time/size-limited
caching within Specialists
* Create virtual sequence classes to implement association collections
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)