[PEAK] STATUS.txt

[Phillip J. Eby]

At 12:11 PM 1/25/04 -0800, darryl wrote:

>model:
>When you say major upheaval are my existing models going to break? Is 
>there anything that we need to watch for/stay away from?

It's too far away as yet to tell.  The main thing is, don't count on the 
existing persistence mechanisms, i.e. _p_jar, _p_oid, _p_deactivate, 
etc.  That's all based on ZODB4 persistence, and Zope Corp seems to have 
shelved ZODB4 for an unknown period.  Also don't rely on the fact that 
attributes are stored in Element objects' dictionaries.

(Yes, parts of PEAK rely on these things, and they will have to be changed, 
too.)

Anyway, mostly it'll be implementation-level changes, not necessarily 
interface.  However, the implementation changes may lead to opportunities 
to improve the interface.  The goal is to move model objects to an 
event-based implementation using events.Value (or something similar) for 
attributes.  Thus, it'll be possible to use event callbacks and threads to 
do things like synchronize a GUI with model objects, use business rules, 
constraints, and even intelligent "agents" ala Argo UML's "critics".  This 
will also interact with peak.query's tabular data management.

Technically, a lot of what I'm referring to will actually be implemented on 
the 'storage' side, with models just becoming less constrained to the 
current storage model.  That is, the idea of what constitutes a "DM" can 
potentially become *much* more varied.