Project Nimrud, or how I learned to stop worrying and love the microsite by Mind Map: Project Nimrud, or how I
learned to stop worrying
and love the microsite
0.0 stars - 0 reviews

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.

Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Sign In