On Sun, 06 Nov 2016 18:19:03 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> Hi,
> 
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
> 
> > However, a web search for ‘vhost site:nginx.org’ returns the
> > following as a first result[0]:
> >
> >    Note: “VirtualHost” is an Apache term. NGINX does not have
> > Virtual hosts, it has “Server Blocks” that use the server_name and
> > listen directives to bind to tcp sockets.
> >
> > I don't use Apache, so that explains that.  
> 
> Oh, good to know.  In general I think it’s best to stick to upstream’s
> terminology.
> 
> Julien, what would you think of changing “virtual host” with “server
> blocks” and “vhost” with “server-block” (?) in the code and
> documentation?
Ok, sorry for the long delay, I was working on php and other things. So
I've been thinking that we should probably stick more to the way you
would write an nginx configuration file, and have an interface to it.
So here is a web.scm file that implements just that. I have a record
type for configuration entries, and record types for complex
configuration types and blocks. Since many blocks can get the same
configuration option (for instance, http, server and location blocks
can get the "root" option), I define a single procedure that returns
the string corresponding to the configuration line. So for instance,
you could write this:

(nginx-service)
(service (service-type
  (name 'foo)
  (extensions
    (list
      (service-extension
        nginx-service-type
         (const (list (nginx-block-server
                        (blocks (list))
                        (configs (list
                                  (nginx-option (type 'server_name)
                                                (value (list 'default)))
                                  (nginx-option (type 'listen)
                                                (value (nginx-listen)))
                                  (nginx-option (type 'root)
                                                (value "/srv/http"))
                                  (nginx-option (type 'index)
                                                (value (list
                                                  "index.html"))))))))))))

As you can see, it's still a bit verbose, but we could provide a few
helper functions for some common cases.

Also, it is now possible to extend the nginx service with other kind of
blocks (although I implemented only the server block, it could be use
to add upstream blocks for instance).

What do you think? should I continue in that direction, or should I go
back to what I was doing before?

> 
> (This is not a fun suggestion to make, but hey!)
> 
> Ludo’.