[PEAK] Persistence styles, MDA, AOP, PyProtocols, and PEAK

[Stephen Waterbury]

Phillip J. Eby wrote:

> This is a rather long article, even for me.  (And that's saying 
> something!)

No argument here!  ;)

> ...   Ask
> me questions, tell me this is crazy, or whatever you want.  Your 
> feedback (including questions) about this plan is respectfully 
> requested, and will be greatly appreciated.

I think it sounds really promising!

The only reasons I'm not using PEAK right now are:

(1)  My app is very Twisted-oriented, and although there has been
some work done on using Twisted and PEAK together, the issues that
my app would encounter in a conversion to PEAK are not well enough
understood right now to give me sufficient confidence.

(2)  PEAK is still evolving in some areas in which I need
more stability.

So basically, I will probably use PEAK in the future once it
has become more stable, added more docs, and acquired a better
portfolio of PEAK/Twisted examples.

BTW, I am making some changes to my app right now to make it more
"ontology-driven" as regards domain objects and their persistence.
Sort of a "limited MDA".  This is strongly motivated by several of
the use cases for my app, which involve ontologies.

It's a very simple-minded architecture relative to PEAK, but
I'd like to get your reaction (even if it's horror :) to this
idea ... in a nutshell:

* Ontological classes of domain objects are represented by
"OntoClass" instances, which are subclasses of dict and
contain "OntoProperty" instances that have a name, type_name
(similar to ontology property "range" concept), max_cardinality
(determines whether they are an aggregate), etc.

* The app domain object classes all have a '_schema' attribute
which is an OntoClass instance, of which the OntoProperty
instances are used in __init__ to create instance attributes.
(I'm not using metaclasses to do this yet, but might do that
in the future ... trying to keep this as simple as possible
for now.  ;)

* The "base ontology" of the app is represented by a package
of corresponding Python classes, for which their class name is
the same as their _schema's OntoClass name (actually '__name' ->
'_OntoClass__name', to avoid collisions).  [Again, I'm not
using metaclasses for this, but it could be done more
elegantly that way, of course.]

* OntoClass instances implement a very simple (ontology-like)
form of OntoProperty inheritance (from their _OntoClass__base).
So new domain object classes, as long as they do not require
new behaviors (as is often the case for the objects that my
app deals with), can be created simply by assigning a new
OntoClass instance that extends the _schema for an object
(this is done for instances only -- class _schema's are not
to be changed).

* The main motivation for this form of extensibility is to
enable the repository's database to be built from the
OntoClasses, which are registered in a registry module and
can be changed at runtime.  The registry is also used in
the marshalling/unmarshalling and repository add/modify
interfaces.

I think it is the "simplest possible thing that works"
(in some sense of "works" ;) for my app, and in keeping it as
simple as possible, I'm hoping that conversion to the more
sophisticated PEAK architecture won't be too difficult
at some point in the future.

Comments welcome!

Cheers,
Steve