** Web Content Management System means an integrated tool
   I want an integrated tool that handles the web server, document
   versioning, static site generation, and everything else that developers
   know how to do today, but can also be used by normal folks. I also want
   a tool that can run locally and remotely the same, like Fossil SCM.

* What this document is
  This is going to be a Literate Programming document that will implement the
  software described above, or at least, some integration testing. I plan on
  using Idris as the language, since it's the newest thing I'm learning, but
  if I'm serious about this idea, then I'd need to implement it in a more
  mainstream language. This will also chronicle the TODO items for this.

  The tangled version of this will actually export Literate Idris files,
  which will then be tangled and woven separately.


* Functional Description
  This is the beginnings of a specification that will be implemented as 

** Web Content Management System means an integrated tool
   I want an integrated tool that handles the web server, document
   versioning, static site generation, and everything else that developers
   know how to do today, but can also be used by normal folks. I also want
   a tool that can run locally and remotely the same, like Fossil SCM.

* What this document is
  This is going to be a Literate Programming document that will contain a few things:
  1. an OpenAPI Specification (swagger) document
  2. Implementations
  3. Tests
  4. TODO lists to write all of these

  I plan on using Python as the language of the prototype, since I've worked
  with Python the longest. However, I also want to implement this in Haskell,
  since I love Haskell.

* Functional Description
  This is the beginnings of a specification that will be implemented as a runnable specification later.
** Interface
   The main interface will be a RESTful web service, likely defined with an
   OpenAPI Specification document. It will behave like a standard web server
   serving up static files. I will leverage code generation tools to create
   the clients. According to the swagger code-gen docs, you can generate a Bash
   client, so that could cover a basic CLI as well.

   If front end or other graphical interfaces would benefit from a secondary
   protocol, we can add that later. The prototypes and alpha/beta versions will
   target the RESTful API only.

** Components
   These are the main components of static, starting from the HTTP service to
   the DB service. The components will start as Idris modules that come together
   in Main.main.

   Each of these components will be Literate Idris files that describe the
   implementation. Therefore, in the long run, this section will be peeled off
   into those documents.
*** HTTP connection
    This service sends and receives HTTP requests. The main requirement for this
    service is to be responsive. This service could be internal to the app, or
    it could be provided by an external service, like Nginx or Apache. The
    internal version will be developed first, and that will be what runs locally
    when you run =static= to view your site. The option to link 

    The first HTTP verb that will be supported is GET, which will form the basis
    of the "documents-as-database" paradigm. Each document path available from
    GET will be mapped to a row in a SQLite database by the other components.

    Other verbs will be needed for the web content management system part, which
    will be one or more front ends to the database. My eventual goal is to build
    an interface that can generate a rudimentary front end that ships with the
    main project, and guides the creation of better front ends.

    This component would encapsulate the effects of interacting with HTTP
    clients.
*** HTTP/SQL Transformer
    This service revolves around one function, =fetch=, a sketch with is here:
    #+BEGIN_EXAMPLE
      fetch : HTTP -> HTTP
      fetch req = toHTTP (toSQL req)
        where
          toSQL : HTTP -> SQL
          toHTTP : SQL -> HTTP
    #+END_EXAMPLE
    The function may have to be split into separate functions, we'll see what
    makes the most sense. It really depends on how complex it is to parse HTML
    and SQL and transform the two into each other. I anticipate complexity.

    This module will be pure, with all the transformations being total functions.
*** sqlite database connection
    This component will connect to the sqlite database where the documents are
    kept. It sends queries, and extracts the document from the query results.
    This component should also do some auditing of the requests to try to
    mitigate attacks, but if that gets involved, that should be made into its
    own component.

    As for the database schema, the naive one is this:
    #+BEGIN_SRC sql
      CREATE TABLE documents (
      id PRIMARY KEY,
      fpath TEXT,
      content BLOB
      )
    #+END_SRC
    The idea here is that each row has a file path and the content. The query to
    get the document would look like this:
    #+BEGIN_SRC sql
      SELECT content FROM documents WHERE fpath = $FPATH
    #+END_SRC
    The =?FPATH= variable would be safely injected by the =fetch= function
    mentioned above. Then, once the DB returns the results of that query, the
    document is serialized into an HTTP response by the transform layer. 

    This component would encapsulate the effects of interfacing with the DB.
*** Main
    =Main.main= would wire up the connections between all the components.