1. Content Types System
1.1. Based on plone's dexterity infrastructure
1.1.1. Export Dexterity schemata
1.2. Few builtin types
1.2.1. Web page
1.2.1.1. Folderish
1.2.1.2. Fields
1.2.1.2.1. Title field
1.2.1.2.2. Rich description field
1.2.1.2.3. Rich text field
1.2.1.3. Viewlets
1.2.1.3.1. List and link children (basic folder listing)
1.2.1.4. Behaviors
1.2.1.4.1. Change default view
1.2.2. Alias/Link
1.2.2.1. Provides a few behaviors
1.2.2.1.1. 301 redirect to an arbitrary URL
1.2.2.1.2. Exact duplication and redisplay of an arbitrary content object (to make it easy to have one content object appear at multiple URLs/folders)
1.2.2.1.3. Serving of any browser view
2. Create revision
2.1. If we have working-copy support, you'd create revisions
3. Plugin points
3.1. Search
3.1.1. Concave will not provide search out of the box, but will fire events when content is changed so that the content can be indexed
3.2. Static file support
3.2.1. Convex should provide a "file" type that it actually manages
3.3. New content type fields
3.4. New Content Types
3.5. Templates for existing types
3.6. Directories of templates
4. UI System
4.1. Site theme provided by deliverance/middleware
4.2. Inner-pages composed of viewlet
4.2.1. Block system for blocks of cross-page or reusable content
4.2.1.1. This could be promo portlets
4.2.1.2. This could also be auto-generated navigation
4.2.2. Query-based blocks
4.2.2.1. This could be how we implement folder listings, file directories, and even eventually a Plone-collection-like system
4.2.2.2. Query types
4.2.2.2.1. Content objects by path
4.2.2.2.2. Content objects by metadata
4.2.3. content-display for any given content type is a viewlet associated with that type
4.2.3.1. This implies when you add a new object of type X, it's some sort of generic "page" that has that type's viewlet display associated with that page by default
4.3. Ability to register new templates through the filesystem for existing content types
4.3.1. We should have a paster template for this
4.4. EXPERIMENTAL IDEA
4.4.1. Nearly is a viewlet
4.4.2. Page templates are templates of DIVs that contain various types of orderable viewlet managers
4.4.3. Webpage is a generic object that can have a template associated and a type associated
4.4.3.1. When you create a new page, you pick which type it will contain
4.4.3.2. The type you pick for the page determines (1) the default layout picked for the page and (2) a viewlet that goes in the manager named "main," which any template must provide
4.4.3.3. Pages can be created without a type, in which case they are "landing" pages and just display viewlets, or alias pages, in which case they can have a viewlet associated with any type in the main area and they will refer to that other content object for content
5. Questions
5.1. Do we have roles?
5.1.1. E.g., Editor, manager, public
5.2. Do we bother to support per-user customized content
5.2.1. I'd say, no
5.3. Do public (non-content-managing) users ever log in?
5.3.1. I'd say no. If you want some sort of collaborative site, use Plone.
5.4. How do we support commenting? Could we just use Disqus and export later?
6. Workflow Support
6.1. hurry.workflow integrated with authorization
6.1.1. Authorization is simple: private, public, editable or not
6.2. Simple working copy support for editing documents
6.2.1. Is this worth the effort? It's not a bad idea.
7. Import/export support
7.1. Exporters
7.1.1. Plone GSXML content
7.1.2. HTML content
7.1.2.1. If all content types can fulfill some sort of IContentPaths interface that exports a list of valid URLs to all content of that type, we could use urllib to just "scrape" the whole site
7.2. Importers
7.2.1. HTML scraper
7.2.1.1. It'd be neat if we could write a rule-based HTML scraper that could spider a bunch of pages and re-create them in concave
7.2.2. Wordpress/Moveable Type importer
7.2.2.1. These have defined export formats that shouldn't be too hard to import as pages
7.2.3. Database Walker
7.2.3.1. Describe, declaratively how to look at some RDB and import its content as pages for systems like Tyop3 and Drupal
7.2.4. Arbitrary data-source importer
7.2.4.1. RSS
7.2.4.2. Flickr
8. Design notes
8.1. Ship with a set of paster templates for creating new skins, content types, and other stuff
8.2. UI Components should be able to tell you where they live on the filesystem
8.3. Connecting a view class to a template should be done through filenaming and directories, over-rideable in the python
9. Filesystem pages
9.1. Provide base-classes for creating sets of file-system pages that are written in ZPT/chameleon and served straight off the file system
9.1.1. Providing the URL exporter for these will be hard
9.1.2. We can use megrok.trails
10. Nonsexy, basic CMS stuff
10.1. Cut, Copy, Paste, Move, Delete
10.2. Undo support
10.2.1. Do we actually care about this?
11. Attractive Future Plugins
11.1. Public content
11.1.1. Allow content types that can be submitted by anon users and workflowed
11.2. Admin UI
11.2.1. Make it easy to browse and manage sets of content, such as public content
11.3. Incoming Feeds
11.3.1. Imports content through the arbitrary data-source importer
11.3.2. Provides a feed-display viewlet
11.3.3. Provides a feed folder that is where you configure that
11.3.3.1. Creates content objects for feed, if that's useful
11.3.3.2. Items can be workflowed if that's useful (for approval)
11.3.4. Provides a many-feed display viewlet
11.3.4.1. This basically aggregates the results of a bunch of feed folders
12. Syndication system
12.1. It should be relatively easy to define an RSS feed for pretty much any collection of content.
12.2. Webpages should have automatic feeds for themselves
13. The ends of our use cases
13.1. Sophisticated workflow support
13.1.1. Review by voting
13.1.2. Group or role-based user content access