Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Wrote out more of the decription of the app |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
4288c65de80008360b88c1dba6a08103 |
User & Date: | sehqlr 2017-11-14 23:09:07.149 |
Context
2017-12-05
| ||
17:19 | more changes to org file check-in: 87058bb2cc user: sehqlr tags: trunk | |
2017-11-14
| ||
23:09 | Wrote out more of the decription of the app check-in: 4288c65de8 user: sehqlr tags: trunk | |
2017-11-10
| ||
18:32 | Add org file, and work from Idris book check-in: 05a19c2cc0 user: sehqlr tags: trunk | |
Changes
Changes to Project.org.
︙ | ︙ | |||
25 26 27 28 29 30 31 | ** 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 | | > > > > | > > > | > > > > > > > > | > > > | > > > > > > > > > > > > > | > > > | > > > > > > > > > > > > > > > > > > | > > > > > > > | > > > > > > > > > > > > > > > > > > > > | 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 | ** 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. |