[TransWarp] peak.model refactoring coming

[Phillip J. Eby]

At 10:29 AM 1/31/03 +0100, Ulrich Eck wrote:
>--On Donnerstag, 30. Januar 2003 19:05 -0500 "Phillip J. Eby" 
><pje at telecommunity.com> wrote:
>
>>* Collection and Reference features will support an aggregation kind 
>>(e.g. indicating that a feature is composite).
>>This is needed to support XMI writing, where the spec requires composite 
>>links to be written in a separate batch from
>>purely referential links.  (It would also be useful for any other 
>>algorithm that wants to do recursive traversal of
>>contained objects.)
>
>Does that mean, that Tree-like structures then can be represented with 
>Collection/Reference features ?

Er, you can do that now, if you mean what I think you mean.  After all, the 
UML model stuff lets you have packages inside of packages inside of packages...


>>* Data manipulation API's and observer hooks.  I'd like to (mostly) 
>>standardize the ways in which features that are
>>collections or mappings can be manipulated, with a goal of making it 
>>easier to implement observability of objects'
>>features.  One tricky bit is the distinction between observing a 
>>collection at one end of an association, versus
>>observing changes in the link set of the association!  The latter is more 
>>useful for storage-ish things, and
>>validation/business rules, while the former is more useful for 
>>GUIs.  Whatever the approach, I'd also like to
>>minimize overhead due to generating events when nobody is actually listening.
>
>what about a concept of Subscribable and SubscriptionAware like it is 
>basically done in Zope3 ?

Well, the "concept" is fine; that's not the issue.  It's the 
details.  Like, whether subscription should be via the data manager or the 
object.  What messages are generated for changes, etc.  Zope 3 doesn't (so 
far as I know) address these issues.  Certainly it doesn't even consider 
the link set vs. end set question, which is one of the bigger issues here.


>>* Validation, constraints, and "business rules".  I have some general 
>>ideas here, but I think I'm going to have to
>>wait until the general refactorings have stabilized more before trying to 
>>put hooks for this in.  Unfortunately, this
>>has a sort of circular depenendency with the previous three items...
>
>How would the be written - python or some sort of OCL ?

That part's not at all important; they could be in Lisp for all I care at 
this level.  :)  It's establishing hooks for them.  I've pretty much 
decided to support "path-based rules" at best, i.e. PEAK won't support 
rules that join arbitrary objects in a "working memory", but instead will 
only allow rules to specify parameters along a traversable set of 
Collections/References.


>>Anyway, I think that about sums it up for now.  So steer clear of 
>>peak.model for now, and if you have any ideas or
>>suggestions about how to sort out any of the open issues above, *please* 
>>speak up, as I could use the help.  ;)
>
>for my refactoring i copied/modified some of the models modules 
>(structural mainly) .. so i'll need to track your
>steps closely :)
>
>any timeframe for this ?

When I have time, and I don't know when that will be.  Still trying to 
finish up the house, and I'm still exceedingly busy at my day job on 
non-PEAK related things.  The only overlap between my regular work and PEAK 
at the moment is investigating "business rule" technology, so I now have a 
better idea of how to integrate a production-rule system with peak.model 
objects.  But not enough yet to know how to map a specific change event to 
a set of rules to be fired, or whether I actually will need timestamp data, 
etc.

If anybody knows where to get a hold of some source code, or better yet, 
*detailed* descriptions of the LEAPS algorithm, let me know.  There are two 
open source rule engines based on Rete algorithm variations out there, but 
nothing LEAPS as far as I can tell.  LEAPS is more suited to path-based 
rules, is "lazier" than Rete, and is likely to have enormously better time 
and memory use characteristics for PEAK's target application 
area.  Unfortunately, I've only found relatively vague descriptions of the 
algorithm that aren't specific enough to do an implementation without a lot 
of hacking and testing to try and get the algorithm right.  :(