1. Plugin points
1.1. Search
1.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
1.2. Static file support
1.2.1. Convex should provide a "file" type that it actually manages
1.3. New content type fields
1.4. New Content Types
1.5. Templates for existing types
1.6. Directories of templates
2. Questions
2.1. Do we have roles?
2.1.1. E.g., Editor, manager, public
2.2. Do we bother to support per-user customized content
2.2.1. I'd say, no
2.3. Do public (non-content-managing) users ever log in?
2.3.1. I'd say no. If you want some sort of collaborative site, use Plone.
2.4. How do we support commenting? Could we just use Disqus and export later?
3. Workflow Support
3.1. hurry.workflow integrated with authorization
3.1.1. Authorization is simple: private, public, editable or not
3.2. Simple working copy support for editing documents
3.2.1. Is this worth the effort? It's not a bad idea.
4. Import/export support
4.1. Exporters
4.1.1. Plone GSXML content
4.1.2. HTML content
4.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
4.2. Importers
4.2.1. HTML scraper
4.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
4.2.2. Wordpress/Moveable Type importer
4.2.2.1. These have defined export formats that shouldn't be too hard to import as pages
4.2.3. Database Walker
4.2.3.1. Describe, declaratively how to look at some RDB and import its content as pages for systems like Tyop3 and Drupal
4.2.4. Arbitrary data-source importer
4.2.4.1. RSS
4.2.4.2. Flickr
5. Design notes
5.1. Ship with a set of paster templates for creating new skins, content types, and other stuff
5.2. UI Components should be able to tell you where they live on the filesystem
5.3. Connecting a view class to a template should be done through filenaming and directories, over-rideable in the python
6. Attractive Future Plugins
6.1. Public content
6.1.1. Allow content types that can be submitted by anon users and workflowed
6.2. Admin UI
6.2.1. Make it easy to browse and manage sets of content, such as public content
6.3. Incoming Feeds
6.3.1. Imports content through the arbitrary data-source importer
6.3.2. Provides a feed-display viewlet
6.3.3. Provides a feed folder that is where you configure that
6.3.3.1. Creates content objects for feed, if that's useful
6.3.3.2. Items can be workflowed if that's useful (for approval)
6.3.4. Provides a many-feed display viewlet
6.3.4.1. This basically aggregates the results of a bunch of feed folders
7. The ends of our use cases
7.1. Sophisticated workflow support
7.1.1. Review by voting
7.1.2. Group or role-based user content access
7.2. Through-the-web page compositing
7.3. Through the web forms
7.4. Real collaborative content authorship and maintenance
7.5. Custom content based on user role or group
8. Content Types System
8.1. Based on plone's dexterity infrastructure
8.1.1. Export Dexterity schemata
8.2. Few builtin types
8.2.1. Web page
8.2.1.1. Folderish
8.2.1.2. Fields
8.2.1.2.1. Title field
8.2.1.2.2. Rich description field
8.2.1.2.3. Rich text field
8.2.1.3. Viewlets
8.2.1.3.1. List and link children (basic folder listing)
8.2.1.4. Behaviors
8.2.1.4.1. Change default view
8.2.2. Alias/Link
8.2.2.1. Provides a few behaviors
8.2.2.1.1. 301 redirect to an arbitrary URL
8.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)
8.2.2.1.3. Serving of any browser view
9. Create revision
9.1. If we have working-copy support, you'd create revisions
10. UI System
10.1. Site theme provided by deliverance/middleware
10.2. Inner-pages composed of viewlet
10.2.1. Block system for blocks of cross-page or reusable content
10.2.1.1. This could be promo portlets
10.2.1.2. This could also be auto-generated navigation
10.2.2. Query-based blocks
10.2.2.1. This could be how we implement folder listings, file directories, and even eventually a Plone-collection-like system
10.2.2.2. Query types
10.2.2.2.1. Content objects by path
10.2.2.2.2. Content objects by metadata
10.2.3. content-display for any given content type is a viewlet associated with that type
10.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
10.3. Ability to register new templates through the filesystem for existing content types
10.3.1. We should have a paster template for this
10.4. EXPERIMENTAL IDEA
10.4.1. Nearly is a viewlet
10.4.2. Page templates are templates of DIVs that contain various types of orderable viewlet managers
10.4.3. Webpage is a generic object that can have a template associated and a type associated
10.4.3.1. When you create a new page, you pick which type it will contain
10.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
10.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
11. Filesystem pages
11.1. Provide base-classes for creating sets of file-system pages that are written in ZPT/chameleon and served straight off the file system
11.1.1. Providing the URL exporter for these will be hard
11.1.2. We can use megrok.trails
12. Nonsexy, basic CMS stuff
12.1. Cut, Copy, Paste, Move, Delete
12.2. Undo support
12.2.1. Do we actually care about this?