Pyogp/Design Decisions

From Second Life Wiki
< Pyogp
Revision as of 11:59, 6 September 2008 by Lillie Yifu (talk | contribs) (→‎ZCA: addign some explanation according to AWGroupies discussion)
Jump to navigation Jump to search

ZCA

What is ZCA?

ZCA stands for Zope Component Architecture. It is a way of binding together the parts of a project. A link which advocates the benefits of ZCA can be found here.

Why A Component Architecture?

Python allows for a component architecture, however, ZCA provides a means to verify that a particular component meets the interface requirments which were designed from th beginning. Crucial is that python is duck-typed, which is a way of saying that if a component meets the requirements to behave in a certain way, then it can substitute for a different class, even if it is not in the inheritence hierarchy of that different class. "If it walks like a duck, swims like a duck, and quacks like a duck, then it is a duck."

A component architecture is a way of describing what functions are needed to be "a duck" in a particular context, and to verify that a particular class meets them.

Is there a good explanaiton of the features of ZCA?

While it describes more feature than are currently in use in pyogp, [1]

Arguments

  1. ZCA allows decoupling. You can simply ask for any class that provides an interface, rather than directly calling that class (and therefore needing all the imports to do so). If you wanted to change, say, the class name, you would have to change all the imports and references to the name. Using ZCA, you can just change the name and keep the interface, it will do the same.
  2. No reinventing the wheel – global registry - zca allows global registration of things like utilities (singleton class that provide some functionality), event subscriber registration, etc. In order for this to happen, need to use ZCA interfaces, adapters, and utilities.
  3. Cleaner code – forces you to define interfaces, and the adapters that use those interfaces. However, this can be done outside of zca. Interfaces exist outside of zca. In fact, zca doesn’t enforce interfaces because Python is dynamically typed language. We can do this (enforce coding to interfaces and using documentation) without ZCA, but we then lose the ability to register with the global registry.
  4. ZCA needs Python 2.4 to run. This is not a problem unless older versions of Python are going to be used with Pyogp.

Examples:

  1. Network layer – swapping the way the client connects to the servers
    • Urllib2, eventlet, mock objects
  2. Packet event handling – we can have packages of packet subscribers. When these packages are included, or used by ZCA, the packets will get handled. If we use a different package, the packets will get handled differently. Allows us to define multiple ways to handle packets. Also allows us to test packets by having the tests be a subscriber and in a package as well.

Buildout

Arguments

  1. Setting up path – we can use buildout to setup our path automatically for development. Without buildout, we would have to set the path ourselves, which would be difficult because of the dependencies and the relation to the system we are on.
  2. Setting up the environment – can use buildout to automatically fetch the dependencies we rely upon (downloading eggs, getting svn projects, etc)