Bright Content's core architecture and design principles

• Use WSGI and REST principles to drive features and modularization. As much as possible one should be able to add features using generic, rather than BC-specific, Web tools

• For content feeds: When in doubt behave as model Weblogs do. The primary model Weblog is Sam Ruby's Intertwingly. Close seconds are Joe Gregorio's BitWorking (e.g. comment feeds) and Mark Nottingham (e.g. feed history).

• Use Atom syntax to the letter, Atom Protocol at least in principle, and XML as long as it does not get too badly in the way.

Bright Content design docs

• Bright_Content/Use_cases

• Bright Content/Weblog/Intertwiningly Examples: some examples of behavior of Intertwingly which inspire design decisions in BC

• Bright_Content/Architecture/Resources: URLs/URIs/IRIs as served by BC, and the organization of file system resources that shape them

• Bright_Content/Architecture/Web_triggers: A basic, REST-based system of component communication in BC

• Bright_Content/Architecture/Templates: Templates in BC

• Bright Content/Architecture/Multiblog: Multiple, composite and syndicated Weblogs in BC

Bundled plug-ins

• Bright Content/Plugins/Annotations

Other key documents

• Atom Syntax

• RFC 4685: Atom feed threads

See also

• http://notes.4suite.org/Bright_Content%3ADesign%3ARaw - Generally chat transcripts that are processed into above design notes

Other notes

• Make sure things are well-tested under proxy scenarios. CherryPy has a nice exemplar test case: http://www.cherrypy.org/browser/trunk/cherrypy/test/test_proxy.py