[TransWarp] New to PEAK

[Phillip J. Eby]

At 09:50 PM 6/17/03 -0500, darryl wrote:
>Thanks for the link.
>
>Well, build P.ython E.nterprise A.pplications of course :)
>
>I think I have some idea of what PyProtocols is all about as
>I've read up on the Zope3 tutorial and the Twisted Components
>howto.

Zope and Twisted interfaces are a very small subset of the functionality 
that PyProtocols offers; where they offer a subtle change to one's coding 
style, PyProtocols has the ability to make a quantum jump in how frameworks 
are used and designed.  PEAK itself is beginning to be transformed by this; 
by the alpha 3 release it should be quite visible, as the use of adaptation 
should be widespread.  If you don't read anything else in the PyProtocols 
docs, read the sections that present examples or coding techniques; those 
should give you a flavor for where PyProtocols is different from "mere" 
interfaces.


>I guess where i'm sticking is how do I figure out what naming
>and binding are about.

In a true "enterprise-class" application environment, many "resources" 
exist, from database servers on the one end, to small objects like 
logfiles, lockfiles, printers, etc. on the other.  Referring to these 
resources by hardcoding in programs is unacceptable; naming services exist 
to allow objects to be referenced by *name* instead of by details such as 
addresses.  One uses naming to associate names with resources.  Also, the 
naming system provides mechanisms for defining name or address 
schemes.  For example, 'peak.naming' implements address schemes like 
"pgsql://user:pass@server/dbname" to describe a database connection.  These 
addresses are then stored in a naming service (which can be as simple as 
using the configuration properties mechanism provided by 'peak.config') for 
lookup by name.

The binding system is really all about creating component hierarchies, and 
linking components together.  You define an "attribute binding" in a class 
that defines how that attribute will be computed.  You can use naming 
system names to define the bindings, so that you can reference other 
components or enterprise resources.

The binding package is the basis for all of PEAK's components, as it's a 
very convenient way to build components in general, and make them highly 
reusable.


>  What i'm looking to do (at least to start)
>is to support plugable backends either file based or SQL etc.

The first thing you do is define your application model, using 'peak.model' 
classes.  Then, you write "data managers" that load or save them from 
whatever format.  The application model is independent of the data managers 
and contains no storage code, only the application logic and data 
structures.  Thus, whatever data manager (DM) components you use them with, 
they will be compatible.  DM's just implement a few methods like '_load()' 
and '_save()', and a few more depending on what features you need that DM 
to have.  Basically, the DM works like a dictionary that you use to 
retrieve items from via their primary key.  But, once you have retrieved an 
object, its attributes will refer to other objects automatically without 
further intervention at the application level.

Typically, an application will have multiple DM components for various 
kinds of application objects.  The DM's are usually arranged in a component 
hierarchy under an application "root" component.

Again, this could be more specific if you had a specific application in mind.