ccPublisher 2:
Architecture & Design

Nathan R. Yergler

Software Engineer,
Creative Commons

Overview

Historical ccPublisher 1 situation
Goals of ccPublisher 2
Architecture of ccPublisher 2
Implementation details

[any material that should appear in print but not on the slide]

The Year Behind Us

ccPublisher 1 grew out of ccTag
Very complex, tightly integrated code
Customization of behavior was difficult

[any material that should appear in print but not on the slide]

Goals for ccPublisher 2

Functional code separation
Easy customization for partners
Extensible for adding features
The ability to update a set of core functionality

In the development of ccPublisher 2, I actually did a partial implementation which implemented a strongly-separated MVC architecture. While this worked, a customizer observed (and I am forced to agree) that he thought 50% of the overhead could be removed without harming the readability or flexibility of the code. So we want to deliniate different functions within the code, but we don't want to impose so much of a burden on the implementor or developer that they have to be aware of the entire system to customize it.

The P6 Architecture

A shared backend library, P6
- Pluggable components using adapters and interfaces
- Internal event system for inter-object communication
Two pieces to a P6 application:
- declaration, the actual code
- configuration, the assembly of the code
P6 encompasses support for metadata, storage, and user interface
These are currently meant to be used as a single entity

As I'm using the P6 library I'm finding places where the intermingling (that seemed logical at the time) doesn't make sense, so some refactoring is ongoing.

The P6 Package

[any material that should appear in print but not on the slide]

Implementation: Terminology

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)

[any material that should appear in print but not on the slide]

Implementation: Configuration

App configuration uses ZCML
Configuration includes:
- metadata declaration
- storage instantiation
- custom component registration
Several custom directives assemble the stock pieces into an application
An application can also register it's own pieces and use them.

[any material that should appear in print but not on the slide]

app.zcml

<configure xmlns="http://namespaces.zope.org/zope"
           xmlns:i18n="http://namespaces.zope.org/i18n"
           i18n_domain="p6">

  <!-- ccPublisher Application Configuration          
       (c) 2005, Nathan R. Yergler, Creative Commons  
       licensed under the GNU GPL 2                   -->

  <!-- P6 package must be included in order to support app configuration -->
  <include package="p6" />

  <!-- Application specific configuration -->
  <include package="ccpublisher" />

[any material that should appear in print but not on the slide]

app.zcml: Storage Registration

  <storage
     name="NoOp Storage"
     factory="p6.storage.basic.BasicStorage"
     />

[any material that should appear in print but not on the slide]

app.zcml: Metadata Declaration

  <metadatagroup
     id="workinfo"
     title="Tell Us About Your Files"
     description="Test description."
     for="p6.storage.interfaces.IWork"
     >

     <field id="holder"
            label="Copyright Holder"
            type="p6.metadata.types.ITextField"
            />

[any material that should appear in print but not on the slide]

app.zcml: Metadata Field Options

     <field id="title"
            label="Title of Work"
            type="p6.metadata.types.ITextField"
            validator="ccpublisher.validators.validateTitle"
            />

     <field id="format"
            label="Work Format"
            type="p6.metadata.types.ISelectionField"
            choices="Other Audio Video Image Text Interactive"
            />

[any material that should appear in print but not on the slide]

app.zcml: UI Assembly

The <pages> directive assembles a list of pages to create the app
A few "stock" pages are included
Applications may create their own and declare them here as well

[any material that should appear in print but not on the slide]

app.zcml: The pages, xrcpage directive

  <pages appid="ccpublisher">

    <xrcpage
        title="Welcome"
        xrcfile="resources/wizard.xrc"
        xrcid="CCTAG_WELCOME"
        />

[any material that should appear in print but not on the slide]

app.zcml: Stock Page Directives

    <fileselector />

    <metadatapages 
	for="p6.storage.interfaces.IWork
             p6.storage.interfaces.IWorkItem
             p6.storage.interfaces.IStorage"  />

    <storepage  />

[any material that should appear in print but not on the slide]

Still In Flux

IMetadataProvider: getting metadata from items, not just the user
Packaging: splitting the core package into it's own sub-installation
Testing: unit testing the framework and UI bits

[any material that should appear in print but not on the slide]

In Conclusion...

ccPublisher 2 will be a huge improvement...
- ...in stability
- ...in performance
- ...in maintainability
- ...in flexibility
the P6 library will be branched when we release ccPublisher 2
other developers such as Jamendo and Ourmedia can build on this easily

[any material that should appear in print but not on the slide]

Thanks!

Questions?

[any material that should appear in print but not on the slide]

CC San Francisco, June 2005