[Subversion] / PEAK / README.txt  

Diff of /PEAK/README.txt

Parent Directory | Revision Log

version 340, Fri Mar 1 19:57:23 2002 UTC version 955, Wed Apr 2 17:45:24 2003 UTC
Line 1 
Line 1 
 TransWarp Release 0.2 preview 1  PEAK Release 0.5 alpha 1
   
  Copyright (C) 2001,2002 by Phillip J. Eby, All rights reserved.   Copyright (C) 1996-2003 by Phillip J. Eby and Tyler C. Sarna.
  This software may be used under the same terms as Zope or Python.   All rights reserved.  This software may be used under the same terms
  THERE ARE ABSOLUTELY NO WARRANTIES OF ANY KIND.  Code quality varies   as Zope or Python.  THERE ARE ABSOLUTELY NO WARRANTIES OF ANY KIND.
  from "alpha" to "experimental pre-alpha".  :)   Code quality varies between modules, from "beta" to "experimental
    pre-alpha".  :)
   
   
  Package Description   Package Description
   
     TransWarp is a toolkit for software automation in Python, where the term      PEAK is the "Python Enterprise Application Kit". If you develop
     "software automation" is considered to include CASE, code templating,      "enterprise" applications with Python, or indeed almost any sort of
     metaprogramming, generative programming, subject- and aspect-oriented      application with Python, PEAK may help you do it faster, easier, on a
     programming, etc.  It is also a collection of frameworks which use the      larger scale, and with fewer defects than ever before. The key is
     toolkit for integration with applications and other frameworks.      component-based development, on a reliable infrastructure.
   
     As Zope is to web publishing, as Twisted Python is to internet protocols,      PEAK is an application kit, and applications are made from components.
     and as AnyGUI is to graphical user interfaces, so TransWarp is (or wants      PEAK provides you with a component architecture, component infrastructure,
     to be) to the guts of your application, whatever its external interface.      and various general-purpose components and component frameworks for
       building applications.  As with J2EE, the idea is to let you stop
     The high-level vision of TransWarp is "Metadata + Metaclasses = Programs".      reinventing architectural and infrastructure wheels, so you can put more
       time into your actual application.
   
  Changes Since Last Release      But PEAK is different from J2EE: it's a single, free implementation of
       simpler API's based on an easier-to-use language that can nonetheless
     Darn near everything.  :)  Read the new docs and tutorials.      scale with better performance than J2EE.
   
       PEAK is the successor to TransWarp, an experimental toolkit for software
       automation in Python.  PEAK takes the best of the techniques and ideas
       from TransWarp, and repackages them as an enterprise software toolkit.
       Where TransWarp emphasized techniques like generative programming and
       aspect-oriented programming, PEAK emphasizes enterprise applications,
       and hides the computer science stuff "under the hood", so you can focus
       on building your application.
   
       PEAK tools can be used with other "Python Enterprise" frameworks such as
       Zope and the Python DBAPI to construct web-based, GUI, or command-line
       applications, interacting with any kind of storage, or with no storage
       at all.  Whatever the application type, PEAK can help you put it together.
   
    Package Features
   
       As of version 0.5a1, PEAK features include:
   
       * A component binding framework that makes it easy to parameterize
         components and thus more easily combine and "wire" them together.
   
       * A comprehensive configuration framework that allows accessing
         "utilities" and "configuration properties" in-context.  Properties
         and utilities can be loaded or computed on demand, supplied by rules,
         defined in configuration files or code, in a supplied or custom
         format.  Properties and utilities are contextual and can be safely
         acquired from parent/context components automatically.  System-wide
         (per Python interpreter), application-wide (per running application
         within an interpreter) and per-component configuration settings
         are available.
   
       * Naming system/framework that's midway between J2EE's JNDI and CORBA's
         cosNaming in features, but much easier to use and extend than either
         of those systems.
   
       * A storage management and persistence system, including:
   
           - Atomic, multi-database transactions with two-phase commit.
   
           - "Data Manager" class framework for persistence management, that
             allows you to separate business logic from storage implementation.
             If you can write a few simple methods like "load" and "save" for
             a given object type and storage approach, you can create your own
             "DM" components.  You can think of a DM as an advanced form of
             Python "shelve", that supports references to other objects,
             transactions, arbitrary back-end storages, and
   
           - "Stackable" data managers: one DM might serialize a set of objects
             to XML, which could then be stored in a database record by another
             DM, and then the database record might be implemented via a DM
             that writes to disk files!  Each DM only needs to know how to
             manipulate objects offered by the next-level DM, not the details
             of the next DM's implementation, so all the DM's are potentially
             replacable with alternate storage mechanisms.
   
           - RDBMS and LDAP connection framework based on the Python DBAPI,
             that handles data type conversions (via the configuration
             framework) and seamlessly integrates with the transaction system
             and naming  services framework.  DB Connections can be accessed
             by name or URL, and bound as default collaborators or utilities
             for access by other application components.
   
       * CASE/modelling tools: PEAK includes APIs to read and write object
         models created in the XML-based XMI format.  Many open-source and
         commercial modelling tools support XMI, inlcuding Argo/Poseidon and
         MagicDraw UML.  PEAK includes pre-built support for UML versions 1.3
         and 1.4, CWM 1.1, and MOF 1.3.1, using XMI versions 1.0 through 1.2.
         Also included, a MOF->Python code generator, which was used to generate
         the UML and CWM support, and which you can use to generate support for
         other modelling languages based on the MOF.
   
         For the specifications of XMI, MOF, CWM, and UML, visit:
         http://www.omg.org/technology/documents/modeling_spec_catalog.htm
   
       * A domain modelling framework for creating "business object models"
         with unidirectional and bidirectional associations, generated
         getters/setters and validators for fields, etc., and all necessary
         persistence support for use with the PEAK storage framework.
   
         The business object framework supplies structural metadata about
         classes built with it, so you can query a class for its fields and
         links, and their names, types, etc.  This can be useful for
         implementing model-driven storage or user interfaces.  And the
         metadata is aligned with the MOF, so generating MOF, UML, or CWM
         from PEAK models (and vice versa) is possible (although
         not yet implemented for anything but MOF->PEAK).
   
       * AOP and SOP: PEAK allows you to separate concerns as modules, then
         combine the modules via a "module inheritance" technique.  This
         lets you define a generated business object model as a
         "structural" concern, and then combine it with a "behavioral"
         concern.  This is as simple as writing classes that just contain
         what you want to add, and then telling PEAK that your new module
         "inherits" from the generated module.
   
   
    Known Issues and Risks of this Version
   
      This is ALPHA software.  Although much of the system is extensively
      tested by a battery of automated tests, it may contain bugs, especially
      in areas not covered by the test suites.  Also, many system interfaces
      are still subject to change.
   
      PEAK includes early copies of Zope 3's 'Interface' and 'Persistence'
      packages, which have since changed names in their official releases,
      and have had - and will continue to have - significant implementation
      changes.  Complete interoperability with Zope 3 is therefore currently
      at risk.  We are waiting until the pending refactoring of Zope 3's
      interface package is complete before upgrading from 'Interface' to
      'zope.interface'.  Also, the ZODB persistence package is undergoing
      some changes that may make it less useful for PEAK, and we may be
      forced to "fork" and/or create our own C-level persistence support.
      This may be clearer once ZODB4 and/or Zope 3 reach their next release.
   
      Documentation at present is limited, and scattered.  The principal
      documentation is an API reference generated from the code's lengthy
      docstrings (which usually contain motivating examples for using that
      class, method, or function).  The mailing list and its archives
      provide a wealth of information on actual usage scenarios,
      recommended approaches, etc.  There is also the beginnings of a
      tutorial on using the component binding package.
   
   
    Third-Party Software Included with PEAK
   
        The 'kjbuckets' module is Copyright Aaron Watters and contributors;
        please see the 'src/kjbuckets/COPYRIGHT.txt' file for details of its
        license.
   
        The 'Interface' and 'Persistence' packages are Copyright Zope Corporation
        and contributors; please see the 'LICENSE.txt' files for details of their
        licenses.
   
   
  Installation Instructions   Installation Instructions
   
     See the INSTALL.txt file.      Please see the INSTALL.txt file.


Generate output suitable for use with a patch program
Legend:
Removed from v.340  
changed lines
  Added in v.955

cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help