Case Study: Rosetta Archive
RP Backstory
--------------
Long Now Foundation
non-profit organization founded in 01996 to deal with imminent Y10k problem
The Clock and the Library
-------------------------
.. image:: http://localhost:8080/rosetta/A1/clockface.jpg
*We hope to creatively foster responsibility in the framework of the next 10,000 years*
- 10,000 year clock
- Library of Everything
the Rosetta Project
-------------------
- archive all human languages
- permanent optical non-digital medium
- preservation by diffusion
see `The Rosetta Disc`__
.. __: http://www.rosettaproject.org/concept/img/disk-front.jpg
Rosetta, the website
---------------------
Online hub for collection and scanning efforts.
Unique in the linguistic world.
Early example of "open" archive
RPv1 Technical
-------------
- Zope 2.2 w/ MySQL
ZClasses, DTML, FSSession
- Archive metadata recreatable from file system.
- online for 5+ years
RPv2: Designing a Platform
--------------------------
- Sexy technologists of linguistics world
- Old functions, new shine
- Platform for integration
Technical Challenges
--------------------
- Representing Language Classification
- Navigating across multiple semantic axes
- Large volume of content
- Emphasis on design
- Interaction with legacy system
Tools
-----
**Core Products**
* **CMFPlone** 2.1ish
ExtendedPathIndex, ResourceRegistries, Archetypes, ATCT, various bits and pieces
* **AdvancedQuery** *http://www.dieter.handshake.de/pyprojects/zope/AdvancedQuery.html*
* **Five** (Zope 2.8) *http://zope.org*
Tools(cont.)
------------
*based on Five*
* **Flon** *http://www.codespeak.net/svn/z3/Flon/*
* **zmori** *svn.plone.org/svn/collective*
* **Sfive** *http://www.codespeak.net/svn/z3/Sfive/*
B-Team
------
* CMFMember
* CMFBibliographyAT (yet to be integrated)
* TextIndexNG2
Tools(cont.)
------------
*other indispensable tools*
* zopectl debug
* ZEO & pound
* subversion
* emacs + grep, DocFinderTab, apidoc, google, pdb, ZopeTestCase
Object Model
------------
**Russian Doll / Fat Stack** *Old School*
- folders within folders. Classic context.
- loose connection to behavior by context (through classic acquisition).
- Classic provision of behavior by subclassing, skins, tools, etc.
- uses classic Plone interface for administration, etc.
Object Model(cont.)
-------------------
**Rich Tapestry** *New School*
- objects interact by references and interfaces
- tight connection to behavior via component architecture
Big Picture (RP Content Types)
------------------------------
- Archive
- Classification Tree
- Lingual Node
- Archive Document
Archive
-------
- container for all archive data
- gives option to use as a zeo mount point
- point to hang rich browsing interface, search tools
- Traversal convenience hooks
- Id management for mass content creation
Classification Tree (INodePath)
-------------------------------
- Language "Family"
- Container for all nodes
- Hub for nodes "hierarchy"
- terminating parent node
Lingual Node (INodePath)
------------------------
- Focal point for presentation of language data
- Focal point of rich navigation
- General container for ANY content type related to a language
- store information about filesystem archive
Screw the Stack
---------------
all this could have been done
with simple folders and marker interfaces.
Zope3
-----
**Brother from another Planet or Back to the Future?**
Five brings ZCML, Interfaces, Views and Adapters to Zope2
*It is simpler than Zope2.*
Upside
------
Component Architecture is JUST a really really nice tool toolkit.
- reduces stacks into simple python objects
- creates points for future extension, making code more reusable and flexible
- makes testing easy, faster and more consistent
- short term increase in initial boilerplate for long term time savings
Downsides
---------
- new paradigm to learn (ZCML, adaptation, etc)
- *must* write tests (should be doing this anyway)
- doesn't yet play nicely with Plone skins straight out of box.
- doesn't completely play nicely with CMF straight out of the box.
Adapters, Views, Javascript, Oh My!!!
-------------------------------------
*zmori* == *MyFirstZ3PloneAdapterViewProduct*
Creates framework for using Geir Landrš's excellent tree javascript *http://www.destroydrop.com/*
- View renders javascript
- View gets data by Interface
- example adapters for nav tree(using Plone2.1 navtree query)
and for static data (files).
Simple things complicated
--------------------------------
**The Tree Widget**
*Relationships*
A. ChildNode -> ParentNode
B. Classification Tree -> A
Tree is architected to allow for extension
Simple things complicated(cont.)
--------------------------------------
all object implementing INodePath can render a tree.
*1 call renders tree*
- uses ExtendedPathIndex in the reference catalog
- uses optimized version of PloneTool nav code to arrange data
- all metadata stored in reference Catalog
Complicated to Simple
---------------------
Using adapters as poor man's generic function
- CalledInterface
- cataloging by Interface
- data return across multiple content types
Catalog, Catalog, Catalog, UID
------------------------------
- **TextIndexNG**: your friend to about 1000 objects
- UID as a portal catalog index
- striking a balance between metadata and computation
Future
------
- Launch
- Community
- Large File Upload
- Desktop Tools
Thanks you!!!!!
---------------
Gabriella Scelta, Fredrique Passot, JD Leahy, Chas Warner, Jim Mason, Laura Buzard-Welcher, Lameen Souag and the rest of the Rosetta Project team.
Kurt Bollacker, Simone Davalos, Ben Keating, Alexander Rose and the Long Now Team.
Rob Miller, Geir Landrš, Dieter Maurer, Philikon, hazmat, runyaga, alecm, Plone Solutions, lurker and all others whose effort, help, and code has made this possible.
Plone Community, #z3-base, #plone, and all the wonderful people who contributed to the laptop replacement fund