Project Nimrud, or how I learned to stop worrying and love the microsite
Principles
Open Source, using a liberal license
This software's goal is to prevent duplicate effort where possible in money-making enterprises
A minimum of technologies
The fewer concepts we have to master, the more likely we are to actually master some concepts
Keep pieces simple
We should hopefully have clearly defined core components that we maintain, For example, concave need not provide many types -- just a rich container will likely do
Core components provide basic services
Each core should provide the services required to build more complicated applications, E.g., concave provides a content types system. Converging provides profiles and user relationships
Provide migration paths in case scope creeps
Migration paths encourage these projects from trying to be everything to everyone, Concave can migrate to Plone. Convex could migrate to Nuxeo or some other ECM.
Components are independent but provide common services to one another
Convex's releases should not depend on Concave, but Convex should integrate with Concave to provide file-management.
Extensions through plugins to defined extension points
Each component should have an API and specified, correct extension points
Feature-growth through distributions
If a group wants a component to offer additional features, they should develop plugins and create a distribution that contains the necessary plugins, tested together
Separation of concepts to separate roles
Common frontend tasks should not require programming skills.
Having lots of different concepts is OK, as long as you don't have to master ALL OF THEM to be competent at customizing the system
Also known for "Pay for only what you eat."
Repeatability is more important than simplicity
Configuration should be serializable to YAML or XML (I don't care which)
Customization is through eggs, buildout, and policy products, You create eggs of your content types, workflows, static pages, user-profile stuff, and then a policy product that orchestrates configuring and installing those eggs
Components
Concave, a Simple Content Management System
Convex, a Simple Digital Asset Management System
Leica, a simple ecommerce system
Yes, this is really more of a pipe-dream than a serious proposal
Converging, a Simple Social Network
Conex, a big pile of experimental code
3rd party components
Use Zine or some other blog to provide blogging in Concave or Grok fire., We'll probably have two different blogging platforms -- Zine for when blogging is separate conceptually but not visually, and probably some hacked-together grok blog for when we want integrated blogging.
Low-level compontents
Plugin installer interface, All of our systems at least can share common code for registering, installing, and initializing plugins
Configuration management, A data-store for components and plugins to store persistent configuration, Automatically generated config forms, Import and export of settings, Import and export could be XML or YAML; I don't care so much which we use, XML keeps our number of concepts to a minium, Can configuration be basically just another content type? Or is that stupid, since each plugin will have only one config, Look at how Generic Setup actually works
Metadata System, All components will ideally add metadata to a common index so that we can have multi-component search, I'd be really interested in looking at RDFLib for this
Authentication Support, Likely just repoze.who integration
Search support
Design
Use WSGI and Grok where possible, with Pylons or Turbogears 2 for data-heavy applications
Ensure that all components can speak the same authentication protocol
Leverage something like Deliverance to provide consistent, cross-component themes
Use z3c.chameleon so we have a common templating language for most tasks
We need some sort of basic page-composition framework and viewlet provider system that could be shared by Convex and Grokfire.
Now called PageParts, At most basic, a template that has access to its context, At most, is a template, a schema, a class implementing schema
Pretty much everything will plug into Convex for storing blob files
Develop on the ZODB, store in the ZODB, deploy with Relstorage
Create Slicehost and Amazon VMs with various distributions to simplify deployment
Problems
Each component has its own authorization concerns and should handle authorization itself, but people might expect authorization to "just work" logically across applications
Theming and template designs are actually pretty tightly integrated, and it's hard to draw a solid line between them
Audiences
Boutique web design and PR firms
Creative, Developers, Integrators, Content and strategy staff, Designers, Sys Admins
Business, Account/sales staff, The client
Do we care about end users at all (that is, random individuals who want a simple CMS for themselves)?
Absolutely non-technical content managers
These are people who don't know HTML, or even what it is
Highly technical content managers
This is a web developer who is caught maintaining a highly customized site.
