[Subversion] / PEAK / CHANGES.txt  

Diff of /PEAK/CHANGES.txt

Parent Directory | Revision Log

version 1110, Sun May 11 20:16:11 2003 UTC version 1180, Tue Jun 10 20:21:26 2003 UTC
Line 2 
Line 2 
   
  Changed, Enhanced, or Newly Deprecated Features   Changed, Enhanced, or Newly Deprecated Features
   
    - Added a 'shellcmd:'  URL scheme that returns a function that calls
      'os.system()' on the body of the URL.  It's intended for use as a command
      factory, as is needed by the 'URLChecker' periodic task.
   
    - You can now define adapters from arbitrary types to 'binding.IBindingNode',
      and thus be able to use them as part of a component hierarchy - without
      needing to directly add 'getParentComponent()' or 'getComponentName()'
      methods to them.
   
    - Added experimental 'invoke.c' script for POSIX-ish platforms with funky
      '#!' support, or lack thereof.  'invoke' is designed to be used like this::
   
        #!/usr/local/bin/invoke peak somearg otherarg...
   
      This should work on most sane platforms with a long-enough commandline.
      (See http://homepages.cwi.nl/~aeb/std/hashexclam-1.html for details on the
      insanely incompatible ways different Unixes interpret #! lines.)
   
      The script is not currently built or installed by setup.py.  On the
      platforms it's targeted at, you should be able to build it with::
   
        gcc -o invoke invoke.c
   
      (Yes, it really is that simple of a script.)
   
    - Added a ZConfig schema for 'running.commands.EventDriven' applications,
      a ZConfig component definition for adaptive tasks, and a running shortcut
      called 'EventDriven'.  It should now be possible to do this::
   
        #!/usr/bin/env peak EventDriven
   
      at the top of a ZConfig file formatted according to the new schema, and
      have it run.  There are two periodic tasks that can be configured and
      run from such a file: 'CleanupFiles' and 'URLChecker'.  'CleanupFiles' will
      delete files matching a pattern that are older than a certain age, while
      'URLChecker' will check to see if the target of a naming system URL is
      up/available/working, and if not, runs a command to restart it.  As an
      amusing demo, try specifying a 'file:' URL with a 'shellcmd:touch theFile'
      to recreate the file, then add a 'CleanupFiles' that deletes the file the
      checker looks for.  This can be hours (well, minutes) of exciting fun as you
      watch the dueling daemons undoing each others' work.
   
    - Added 'zconfig.schema' URL scheme that loads an enhanced ZConfig schema
      object that can act as a command line interpreter using the 'peak' script.
      To use it, run 'peak zconfig.schema:urlToSchema urlOfConfig'.  Or, add
      a line like this::
   
        #!/usr/bin/env peak zconfig.schema:pkgfile:some.package/schema.xml
   
      to the top of a configuration file, and make the configuration file
      executable.  Note that the schema specified must convert to an object
      that's usable with the commands bootstrap framework.  Also note that
      if you have a local PEAK_CONFIG file, you can add a 'peak.running.shortcuts'
      entry to shorten the URL reference in your #! line.  E.g.::
   
        #!/usr/bin/env peak mySchema
   
      will suffice if you have defined 'peak.running.shortcuts.mySchema' as
      'naming.LinkRef("zconfig.schema:pkgfile:some.package/schema.xml")'.
   
      There is also a 'peak ZConfig urlOfSchema urlOfConfig' variant, that was
      added to support putting '#!/usr/bin/env peak ZConfig' at the top of
      schema files, but unfortunately that's not valid XML.
   
    - Standardized file-based URL syntaxes (e.g logfiles and lockfiles) to
      follow RFC 1738/2396, and Python 'urllib'.  This shouldn't affect much
      besides the canonical forms of the URLs.  Added 'pkgfile:some.pkg/filepath'
      URL syntax for ease of referring to files near modules.  (A convenience
      intended mainly for referencing ZConfig schemas.)
   
    - Added the UML 1.4 metamodel, and thus the ability to load UML 1.4
      models encoded in XMI 1.1.
   
    - Added support in the mof2py code generator for "unprefixing" enumerated
      values, so that UML and other metamodels' enumerations work correctly
      when loading from XMI.  Also, mof2py no longer emits 'config.setupModule()'
      calls in generated code, as in practice they are not needed.
   
    - Running 'peak test' from the command line is roughly equivalent to running
      'unittest.py', except that the test suite defaults to the PEAK test suite.
      You can, however run any test suite from the command line with a dotted
      module/attribute path, e.g 'peak test foo.bar.test_suite'.
   
    - 'binding.Acquire()' now accepts a 'default' value argument, and
      'binding.New()' no longer accepts the 'bindToOwner' flag.
   
    - There is a new 'binding.IComponentKey' interface that is used to implement
      'IComponent.lookupComponent()'.  Now you can implement this interface,
      or create an adapter for it, in order to make an object usable as an
      argument to 'binding.lookupComponent()' - and therefore usable as a key
      for 'binding.bindTo()' or 'binding.bindToSequence()'.  Not that it's
      necessarily very useful to do so; you're probably better off simply
      creating a naming scheme.  But it might be useful for lookups done
      in the context of classes, since naming schemes aren't usable there.
      (It was actually added in order to factor out all the type testing that
      'lookupComponent' used to do, so it doesn't matter if it's useful for
      much else.)
   
    - PEAK has been refactored to avoid the use of 'isImplementedBy()' and
      similar introspection, in favor of 'adapt()'.  As a result, some
      'peak.naming' interfaces have changed.  This should not affect you
      if you are only subclassing PEAK-provided naming components and not
      implementing these interfaces "from scratch".  However, the various
      'isAddress', 'isAddressClass', 'isResolver', and 'isName' APIs have
      also been removed, as they were based on 'isImplementedBy()'.
   
  - REMOVED ability to use '__implements__' and '__class_implements__' to   - REMOVED ability to use '__implements__' and '__class_implements__' to
    declare support for interfaces.  Use 'implements()', 'classProvides()',     declare support for interfaces.  Use 'protocols.advise()' or a related
    'directlyProvides()', 'moduleProvides()', etc. to do this now; they     API to do this now.  The 'protocols' package is available automatically
    are now available automatically from 'peak.api'.     from 'peak.api'.
   
      Similarly, the ability  to use 'isImplementedBy()' with interfaces declared
      by PEAK is REMOVED.  You can still use 'isImplementedBy()' with Zope
      interfaces, of course, but we recommend you switch to 'adapt()', which
      should work with both PEAK and Zope interfaces.
   
  - Replaced all use of 'zope.interface' with 'peak.interface' because   - Replaced all use of 'zope.interface' with 'protocols' package because
    the new 'peak.interface':     the 'protocols' package:
   
    * is considerably smaller and simpler than 'zope.interface'     * is considerably smaller and simpler than 'zope.interface'
   
Line 21 
Line 132 
      adapts from A to B, and adapter BC adapts from B to C, then an adapt(x,C)       adapts from A to B, and adapter BC adapts from B to C, then an adapt(x,C)
      where 'x' is an 'A', will be implemented as BC(AB(x)).       where 'x' is an 'A', will be implemented as BC(AB(x)).
   
      * Supports "open protocols" that allow you to "superclass" a protocol
        to create a subset protocol; objects that support the first protocol
        will automatically support the subset protocol.  For example, if one
        person defines a "dictionary" protocol, someone else can create a
        "read-only dictionary" protocol, and all objects supporting the
        "dictionary protocol" will be considered to implement the "read-only
        dictionary" protocol.
   
    * can interoperate with other interface packages, including Zope's, but     * can interoperate with other interface packages, including Zope's, but
      does not require them       does not require them
   
    * works with module inheritance (for everything but moduleProvides())     * works with module inheritance (for everything but moduleProvides(), and
        we should get to that by 0.5a2)
   
    * lets you use Interfaces as abstract base classes (i.e., you can     * lets you use Interfaces as abstract base classes (i.e., you can
      inherit from an interface and turn it into an implementation, and       inherit from an interface and turn it into an implementation, and
Line 35 
Line 155 
      any number of interface types, in a single 'implements()' or       any number of interface types, in a single 'implements()' or
      'classProvides()'       'classProvides()'
   
      * uses adaptation as the fundamental approach to dealing with interfaces,
        and avoids the use of 'isImplementedBy()'.  In the *rare* case that you
        need to introspect rather than adapt, you can always call adapt() and
        check the result.  (But introspection usually means that you're using
        interfaces as a form of metadata; it's better to create an explicit
        interface that provides the metadata you seek, and adapt to that
        interface, than to use interfaces as data.)
   
    Most of these features are unavailable in 'zope.interface', and some have     Most of these features are unavailable in 'zope.interface', and some have
    been declared by the Zope Pope to be unacceptable or undesirable features     been declared by the Zope Pope to be unacceptable or undesirable features
    for Zope interfaces.  (Others may be available in some form in future     for Zope interfaces.  (Others may be available in some form in future
Line 48 
Line 176 
    about this, as they are part of the naming package's extensibility     about this, as they are part of the naming package's extensibility
    framework.)     framework.)
   
  - 'EigenRegistry' and 'PropertyMap' no longer attempt to figure out whether  
    implied (i.e. inherited) interfaces are more or less general with respect  
    to a previous registration.  This was behavior that emulated Zope adapter  
    registries, but what we really wanted was more akin to a Zope "type"  
    registry.  The only parts of the test suite that used the old behavior  
    were the tests specifically written to ensure that behavior!  
   
  - 'binding.bindTo()' now accepts a 'default=' argument, whose value will be   - 'binding.bindTo()' now accepts a 'default=' argument, whose value will be
    used in case of a 'NameNotFound' error.     used in case of a 'NameNotFound' error.
   
Line 63 
Line 184 
    provides a new URL parsing framework based on 'peak.model'.  Upgrading from     provides a new URL parsing framework based on 'peak.model'.  Upgrading from
    'ParsedURL' to 'URL.Base' is trivial for ParsedURL subclasses that used     'ParsedURL' to 'URL.Base' is trivial for ParsedURL subclasses that used
    only the 'scheme' and 'body' fields, and in fact may not require any     only the 'scheme' and 'body' fields, and in fact may not require any
    changes except for the choice of base class.     changes except for the choice of base class.  Also, the 'retrieve()' method
      of URLs is deprecated; please begin defining the 'getObjectInstance()'
      method instead.  This is to cut down a bit on the number of ways that the
      naming package spells the idea of retrieving something!
   
    For more complex URL classes, the '__init__' methods go away, 'parse'     For more complex URL classes, the '__init__' methods go away, 'parse'
    methods change slightly, and explicit field definitions (using     methods change slightly, and explicit field definitions (using
Line 113 
Line 237 
   
  Corrected Problems   Corrected Problems
   
    - Fixed a problem in ZConfig 'schema.dtd'; I used 'PCDATA' where I should've
      used 'CDATA'.
   
    - Fixed a problem with 'binding.supertype()' not working correctly if the MRO
      it was searching contained a "classic" class.  Now 'supertype()' skips any
      classic classes it finds.  (It probably should be rewritten entirely.)
   
    - Fixed misc. problems with 'fromZConfig()' component constructor
   
    - Fixed source distributions missing essential setup files
   
    - Fixed a problem with assembly events, where a parent component that didn't
      need assembly notification, wouldn't ever notify its children of assembly
      if they requested the notification after the parent had already received
      it.
   
    - Fixed a bug in automatic metaclass generation that caused extra unneeded
      metaclasses to be generated.
   
  - Fixed 'naming.lookup()' and related APIs not setting the parent component   - Fixed 'naming.lookup()' and related APIs not setting the parent component
    of created objects without an explicitly supplied 'creationParent' keyword     of created objects without an explicitly supplied 'creationParent' keyword
    argument.  This used to "sort of work" when we had implicit configuration     argument.  This used to "sort of work" when we had implicit configuration


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

cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help