Heroku support #221

Merged
merged 11 commits into from May 7, 2012

2 participants

@harlantwood

I've come up with a somewhat cleaner way to support recursive calls on heroku, which also allows for more efficient serving of json and favicons that are already on the local server (ie it is useful for non-heroku hosts too).

By setting the env var:

FARM_DOMAINS=my-sfw-farm.org

You are instructing your server to handle "remote" calls locally for all subdomains of my-sfw-farm.org. More on this in the README.

I did a fair bit of refactoring along the way, including moving the server helpers into their own module, to allow rspec testing of the new helper method #serve_resources_locally?.

I also pulled out a serve_page helper, now that it is used in two places, as well as Favicon#get_or_create, same story.

The changes in CouchStore are from a refactoring teased out by the previous approach (seeing if there are any pages present for the given server), which I've left in place because it is clearer code.

@harlantwood harlantwood referenced this pull request May 7, 2012
Closed

Heroku deployability #190

@WardCunningham

Wonderful. I can't wait to launch some servers.

A question about philosophy: I wonder if it is desirable to copy pages from default-pages when read? The convention with remote pages is copy-on-write.

I ask this because I would like to include sample pages with each plugin but I wouldn't expect them to pollute the users own page space.

Can you suggest how serving pages from the plugin directories should be handled based on abstractions that you've made? I can imagine some generated page, like recent-changes, that enumerates installed-plugins.

Here are some sample plugin pages: https://github.com/WardCunningham/Smallest-Federated-Wiki/tree/master/client/plugins/metabolism

@harlantwood

Some useful commands for setting up your heroku app:

heroku config:set STORE_TYPE=CouchStore
heroku config:set COUCHDB_URL=xxx  # Your couchdb URL, eg from https://addons.heroku.com/cloudant

If you want farm mode:

heroku config:set FARM_MODE=true
heroku config:set FARM_DOMAINS=my-sfw-farm.org
@harlantwood

Can you suggest how serving pages from the plugin directories should be handled based on abstractions that you've made? I can imagine some generated page, like recent-changes, that enumerates installed-plugins.

Anything that is checked into the git project we can safely serve up from the file system. It's only "dynamic" files that have to live in the Store layers.

I wonder if it is desirable to copy pages from default-pages when read?

It seems useful for the "home page" of each site, less so for other pages, especially if we have another system for plugin-related pages (eg some way to get what we now get with the default pages d3-*). The home page copying could happen on site creation instead of on read.

@WardCunningham WardCunningham merged commit ff5d8cf into WardCunningham:master May 7, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment