[Dev] Spike sandbox and next steps

[Lisa Dusseault]

You might have noticed a bunch of checkins to a sandbox called "Spike", 
or even browsed some of the API documentation in Spike.  Our first goal 
with this project  was to demonstrate an architecture that would allow 
us to test pieces of our content model in isolation, without the 
requirement for an active repository to be running.  Along with that, 
Phillip wanted to experiment with a way to provide a Python API for 
defining a parcel's schema and behavior in a single file, and use the 
process of developing Spike to learn more about Chandler's requirements 
and what parts of its design could be simplified for new developers in 
and out of OSAF.

Now that Spike is at the point where people can start to see the 
architecture and play with it, and as people wind down with 0.5 bugs, 
here's a rough plan how to use Spike:

  - Consult with Andi and Ted about how to "split" the repository from 
our content model.
  - Consult with Morgen and Grant about parcel loading
  - Consult with Alec, Jeffrey and Brian K on the calendar and email 
domain models
  - Consult with John, Brian K and Ted on notification/events

Of course there may be other interesting topics and other interested 
people so please do chime in.  The documentation is in there with the 
code as doctest files  (the .txt files), simultaneously explaining and 
testing the source file when you run Spike's tests.  The README.txt 
file is a good place to start for information on installing Spike and 
running the tests, and overview.txt describes the general plan of 
Spike's development.

http://cvs.osafoundation.org/viewcvs.cgi/internal/Spike/

Other ideas to note in Spike and perhaps pursue sooner or later
  - Other aspects of the layered architecture, such as more strict 
model/presentation layering
  - Stamping by composition

Lisa