Package resources should probably be in a package director inst/resources (much like rstudio/markdown currently does), and then when someone creates a new blog, this entire directory would get copied so that the person can make any necessary changes to any of the templates, css, etc.

What are the options for rendering the pages?

Templating and using RHTML seems like an interesting option, but I'm not sure how well it will work. The other way is to do something similar to the markdown package.

I like the idea of doing RHTML and knitting the page, because this allows us to do normal R function calls, and let knitr take care of it all. But, some elements in the page probably can't be modified by knitr (thinking in the header, etc).

See what happens if we put functions in the header, etc of an RHTML page.

how do we store old posts? Should we have an R object on disk with the date, content, original file name, and an md5 hash of the original file?

This could then be compared with the current files in the source directory, and stuff redone only if it has actually changed. This is a way off, but will probably become important as a given blog grows.

Default behavior of title links would be to link to the post itself, but provide a way for the title to link to something else, but the date on the post should always link to the post!

When a post is generated, it's date information should be saved, and then parsed to figure out the order of the posts to display on the front page.

Document the functions using roxygen so we don't have to write separate documents.

the output html filename should be based on the post title supplied in the options, along with the date.

```{r postOptions}
layout <- "post"
title <- "This is my first post!"
date <- Sys.time()
comments <- TRUE
tags <- c("first", "post")

This should also use a custom hook that takes these options and copies them to the parent environment so that they can be used to set options for the file that will be written.