-*- outline -*-

*Things I can do now that may be in the right direction

- Implement or subclass (for HTTP) and implement View
- Get index.cgi to output /something/
- Write a calendar store
- Try multiple projections in the model

*Basic implementation tasks and questions

**Test cases for what I've done at least

**Decide on the interface to the model
.. and make sure the view (projection) uses it

- Implement Lists and so on, and have some consistent interface for
configuring it.  May need to have a Resource subclass for existential
nodes.

- Formulate the rules and data structures for finding things like
templates, rules, selectors, etc.

- The projection is now a part of the model, in that it is the
metadata and entailments that determine what resource the model hands
back.

**Implement default view, controller

- How does the view get a stylesheet?  I expect it is part of config.

- What is the controller abstraction?  Accept an event, do something
with it.  Making the event from the request is part of the
scaffolding.

**Parameterise FilesystemStore
- A map from RFC822 headers to RDF predicates would be useful.  This
could be given as metadata -- rdfs linking RFC822 header to property
(to label to ..) or something -- and taken from a store.

- Textual interpolation -- how will this work?  It could given rise to
further relationships.  Embedded links can be given fragment
identifiers to allow them to be referred to as resources.  But when is
this done, and how do I know when to look up everything?

**Stylesheets
Decide on an implementation strategy and go for it.

- It would be neat to be able to reflect stylesheets (rules and
templates) in a store somehow.

- Perhaps the one to go for is a file store with fill-in-the-slots
templates, per class maybe.  Templates with repetition or what-not can be
constructed procedurally, or a little-language invented or co-opted.

Haystack has a distinction between group lenses and regular lenses
that may be useful to adopt -- group lenses can be done
programmatically (there can be standard ones) and regular ones can be
fill-in-the-slots.

***The flavour is important

Where does it come in?  It is /kind of/ something that should be
passed as part of the subject, but then we want the model to be 'dumb'
with respect to splitting strings.  That should go in a store; perhaps
a specialised mapping store.  The mapping store should be treated the
same as other stores (will it need to know about the others though?).
The flavour can then be a part of the resulting Resource, which can be
given to the view to render.

***How are selectors represented?

- This could be done in RDF lists, even; it's just another little
language, though, so perhaps reflecting it as RDF is enough.

- Could use graphpath, and instantiate with particular subjects --
perhaps a
Context expression node, that is parameterised with a context that
supplies the current node when evaluating?

**Support for scaffolding
- Make an adapter from requests to input events
- Configuration .. somehow ..

**Dynamic rendering

**Static rendering

- Needs support in the model for finding all subjects -- this can come
directly from the store[s], along with some type information (either
information about the type, or just check the type).

**Rendering server

Some gains from persistence between requests.

**Fuschia site using Fuschia

*Features
Over and above the minimal dynamic and static rendering.

**Calendar view
Using the time-stamp, either mtime or header.  Can be a different
store looking at the same place, or perhaps a inference rules in the model.

**Changes log
Like changing the semantic relations you consider as categories/stories.

**Gallery
A picture gallery.  Not sure how it differs from a normal blog view =)

*Things to do that might be fun/useful

**Filters
- Wikiwordish (use filenames as page headers, or titles)
- Wiki markup (rip off pyle rendering, or otherwise)

**Variables
- Breadcrumb trail of categories
- Backlinks (!), based on story.name perhaps

**More graceful failures
- More fallbacks in the case that variables or templates aren't found.
- 404s passed back from the store properly

**Other stores
- XML store
- GNU/Arch and DARCS and CVS

**Closures
- Use XForms for closures (in the Haystack-y sense)