[Written to the xxxxxx@ mailing list and cc'd to xxxxxx@]

Good news. Arthur contacted esteemed Schemer Shriram Krishnamurthi who
owns the domain names <scheme.org> and <schemers.org> to inquire if we
could use subdomains there to host our Scheme documentation
aggregator. Happily, Shriram liked the idea and is willing to update
DNS records to point to our server.

So we'd need to decide where to host. I registered a VPS at Vultr.com
which is cheap (starting at 3.50 USD/month) and has a very good
reputation on Hacker News. We can keep using that VPS, or if you have
other suggestions let's explore them. Some Schemers would like to
avoid the platform-as-a-service offerings of household-name providers
such as Amazon, Google and Heroku. This means it would be politically
and technically simplest to use a Linux VPS from a smaller provider
such as Linode or Vultr. I would avoid providers smaller than these as
the experience is unlikely to be as streamlined and polished; since
this is a volunteer project, it is also important to keep avoidable
technical complications to a minimum. For this reason, using a VPS
provider instead of our own physical server is also simplest.

With regard to the subdomains, my suggestion would be to have one for
the REST API and another for a default web front-end for browsing it.
The plan is to make an easy API based on a comprehensive dataset and
to cover people's diverse and evolving needs by letting anyone write a
client for it (we already talked about exploring web, command line and
Emacs clients; doubtless there could be several other kinds as well).
The default web front-end would be important as an obvious destination
for new Scheme programmers so that they are not overwhelmed by choice
right away. Meanwhile, if that front-end is on a different subdomain
from the API itself, it forces us to be honest in designing the API so
that it is future-proof and equally useful to all clients, not taking
design shortcuts to favor one frontend. The subdomains could be named:

api.scheme(rs).org
doc.scheme(rs).org

I would further suggest having separate staging instances of these
services so that when we make a change we can first push it out to
staging to verify that it works in an environment that closely matches
production yet does not affect production users if something goes
wrong. These could be:

api.staging.scheme.foo.org
doc.staging.scheme.foo.org

(Here "foo.org" is a stand-in for someone's personal domain. For
example, Arthur and myself both have our own domains where we can
freely add as many subdomains as we like. It doesn't really matter
under what domain the staging versions are hosted as they are only
used for testing purposes by people who develop the API. They can also
be moved from one domain to another if need be, whereas it'd be nice
to keep the production versions perpetually in one place.)

(It would also be possible to have production and staging under the
same subdomain, with the staging versions of URLs under a /staging URL
path, but web technology is designed so that it's easiest to have one
subdomain per site. For example, URLs that start with a slash / are
relative to the subdomain's root path. SSL certificates also work on a
domain/subdomain basis instead of paths.)

All of the four subdomains could point to the same IP address (our
VPS). We can install Nginx on the VPS and have it differentiate
between the subdomains by using the HTTP Host: header (which is the
standard way to do such differentiation). doc and doc.staging could be
static sites (driven by HTML, CSS JavaScript, all of which we could
generate from Scheme -- several Scheme-to-JavaScript transpilers
already exist). api and api.staging can each run their own copy of a
Scheme implementation to serve the REST API (Frank wrote tentative
code using Guile and we are planning to start by expanding on it).

I am willing to take primary responsibility for setting up and hosting
the server but will gladly share admin/coding responsibilities with
anyone who is interested in helping. I'll write and share an Ansible
configuration for the server so there is executable documentation on
how it is built. Arthur can take on the financial burden provided we
use a cheap VPS. He can also assist with running the server now and
then. Frank is especially interested in exploring clients for the APIs
and will likely also do some work on the server. If anyone who is
experienced with Scheme-based web dev is interested in advising us or
writing some code, that would be great.

Comments and suggestions on any/all of the above are welcome.