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/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
Other key documents
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
