CcPublisher 2 Architecture
Template:Needs updated This document outlines the architecture developed for ccPublisher 2.x. At this point it is still considered a draft and subject to change. No applications based on the ccP 2.x codebase have been released. ccPublisher 2.0 will be the first application released using this code base, probably in February 2006.
The following are goals we've attempted to meet while developing ccPublisher 2.x:
- Cleanly separate the User Interface from Internet Archive/uploading components
- Functional code separation
- Easy customization for partners
- Extensible for adding features
- without doing a complete customization
- to existing applications in a reasonable amount of time
- The ability to update a set of core functionality
- Allow for straight forward customization of the application. "Straight forward" means that elements of the user interface have a minimal number of interconnection points, and program logic is contained in a central location.
The following are considered non-goals:
- A general purpose application framework. Certain architectural details exist because ccPublisher and it's derivatives have common functionality: collecting information and uploading files. While individual pieces of code may be useful for other applications, the platform is designed to support this particular model.
- Addition of embedding support for more file types; this will be addressed in a release following 2.0.
- A P6 application is designed to take a "Work" and send it somewhere
- A Work may contain one or more "items", such as files, CD tracks, etc
- A "Storage Provider" is responsible for taking the work and performing the action on it
- Metadata fields may be applied to any object:
- the work
- each item
- the storage provider (i.e., for username and password)
High Level Overview
The core of ccPublisher 2 is the P6 library, a set of common code intended to be used as a whole to perform core actions. P6 Applications consist of two phases: declaration and configuration. Declaration is the development of objects, event listeners and other code. Configuration consists of instantiating and connecting that code.
Configuration is handled through the use of ZCML, the Zope Configuration Markup Language. The ZCML directives configure adapters, event listeners and objects to instantiate. It also defines metadata fields to include in the uploaded package. Finally, the configuration can be arbitrarily extended using 3rd-party ZCML snippets to register new functionality. One example of this might be a blog pinging extension which posts a blog entry when new content is uploaded using a P6 Application. Note that depending on the registration mechanism used, it is possible to add content to all P6 Applications installed on a user's system.
In addition to ZCML, P6 uses the Interface and Component model from the Zope3 project. We maintain a snapshot in the CC Tools CVS Repository.
- ccPublisher 2: Architecture & Design
Slides from a talk Nathan gave at CC San Francisco, June, 2005.
- ZCML in the Zope3 Repository
The P6 Package
The P6 package forms the core functionality of ccPublisher 2 and related applications. This section provides an overview of the sub-packages and modules developers should be aware of. For more detailed documentation of specific items, see the Epydoc documentation at http://mirrors.creativecommons.org/developer/doc/p6/current/. Note that some subpackages, such as p6.configure and p6.zcmlsupport, only provide internal support for bootstrapping applications.
The p6.api module provides a sub-set of functionality from other p6 sub-packages. The api module is intended to provide a simple way to import commonly needed functionality.
The p6.app package collects application-level functionality, including top-level window classes. This may be merged into p6.ui in a future release.
A core piece of functionality for P6 applications is the collection of metadata. The p6.metadata package provides interfaces for encapsulates metadata fields and metadata groups. A metadata field is a single piece of information, such as artist or title. A metadata group provides a logical grouping for one or more fields. A metadata group may also be associated with a particular type of item or interface. The p6.ui package introspect this information for generating a user interface.
The p6.storage package encapsulates the interfaces used for Works, Items, and backend "storage" providers. The current implementation includes generic interfaces, interfaces for file-based items, and a generic No-Op storage provider. For an example of a custom storage provider, see the ArchiveStorage class in the ccPublisher distribution.
The p6.ui package provides three primary pieces of functionality: user interface generation for metadata groups and fields, stock wizard pages, and interfaces for custom wizard pages. It also includes a sample, custom page in the form of the license selector wizard page (license.py).