Case Study: Rosetta Archive

Whit Morriss talks about the Rosetta Archive project.

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