The Padliography is a tool to keep track of our pads. It is built to interact with the MediaWiki API, and it uses [XPUB & Lens-Based Wiki](https://pzwiki.wdka.nl/mediadesign/Main_Page)'s pages as archive.
The Padliography homepage loads by default the XPUB2 archive. Just above the pads list it is indicated from where the pads are being fetched, and it is possible to change source by inserting the title of the page in which the other archive is.
To create a brand new archive click on `Init a new padliography` and insert a title and a short description to put in the wiki.
**Watch out:** This action will create a new blank page, so check that there is not already something with the same title in the wiki, or it will be overwritten. Thanks to the wiki's history, it is possible to recover overwritten contents, so the contents are not in total danger.
Use the **Add new pad** form to insert a pad in the archive. The required information are a title, the URL of the document, a short description, a date and some categories. The categories are custom, and are useful to organize pads in themes or context.
At the moment this Padliography instance runs on the [Soupboat](https://hub.xpub.nl/soupboat/). If you are using it a lot or with a lot of pads, consider to install a new instance on a different environment, in order not to put a strain on the small Raspberry. It should be fine anyway.
The pads are stored in a page with a minimal template, such as the title, a short description and a section named Padliography with the archive. Here they are organized in a table that has the CSS class `padliography`.
Through the [MediaWiki API](https://pzwiki.wdka.nl/mediadesign/Special:ApiSandbox) we can request the contents of this page from somewhere else. This somewhere else is a small Raspberry Pi called Soupboat and installed on the 4th floor of the WdKA.
The Soupboat is a small server, and it runs a [Flask](https://flask.palletsprojects.com/en/2.2.x/) application that interacts with the wiki using the [mwclient](https://mwclient.readthedocs.io/en/latest/index.html) python library.
When a user enters the homepage of the padliography, the Flask application returns a [Vue3](https://vuejs.org/) app and through that requests to the wiki API the list of pads.
The response from the MediaWiki API is parsed on the server using [BeautifulSoup](https://www.crummy.com/software/BeautifulSoup/), that tries to find the `padliography` table with some CSS selectors and then builds a list of pads organized by the properties of the table's headers. The list of table is sent to the Vue app as JSON message, and used to compile a fancy sortable table and filtering system.
When a user interacts with the form to add a new pad the process is the same, but in the opposite direction: first the Vue app sends the data to the Flask application that in turns tries to add it in the archive wiki page.
To install the Padliography somewhere else start by cloning this repo.
```
git clone https://git.xpub.nl/kamo/pad-bis.git
```
Then move to the cloned repository folder and create a python virtual environment.
```
cd pad-bis
python3 -m venv venv
```
Activate the virtual environment
```
# on unix
source venv/bin/activate
# on windows
venv\Scripts\activate
```
and then install the requirements with pip. The **.** here refers to the current working directory, where the **setup.py** file can be found. There are specified all the packages the application needs.
```
pip install -e .
```
Once the installation is completed, launch the application and open it on the default port .
```
python pad-bis.py
```
If you open `localhost:5000` on your browser, it will return the padliography stuck in the loading process. This is why before interacting with the MediaWiki API we need to specify the credential for a user to log into the wiki. On your local version you can use your own credentials, but if you plan to put this padliography online it's better to use a dedicated user, aka a bot.
Remember not to commit your credentials on git, or they will be rendered public! Instead create and `.env` file, that will not be uploaded on git as specified in the `.gitignore` file.
Create an `.env` file in your working directory with the following properties:
```
MW_BOT= your username
MW_KEY= your password
```
At this step you are up and running, the padliography should be able to fetch the pad from the wiki etc.
Going online depends on several variables, many of them being out of reach.
For this reason this section doesn't provide a comprehensive guide to put the project online, but just a reference to the configuration currently in use on the Soupboat.
There are so many technical terms I'm not confortable _just using_, so I need to negotiate a glossary.
Sometimes to find alternatives: like what happened with the naming of default branch in platforms such as GitHub, that switched from `master` to `main` in order to stop using terms related to slavery.
Sometimes to retreace genealogies, that is: to offer other contexts for a word to refer to. A redemption arc for cursed words. No clue how to do it though, a way could be to use them critically, stumbling upon them, connnecting with different images. So here some attempts.
Deployment in software and web application means to push changes from a development environment to a production one. To move and install the code from your computer to a server, for example.
When writing a piece of documentation together with my friend Chae, she reacted puzzled to my generic use of this very specific word? I reacted puzzled to this puzzlessness, and went searching for the real-world meaning of a term imported and naturalized in the technical jargon.
Deployment is a military term, that refers to moving troops and army around on the battlefield. The spatiality of this gesture, going from home to the warzone, or from a target to another, suggests a form of detachment from its consequences, rendering them far away. Do we feel less responsible for what's happening so far? Perhaps the contrary. When something goes wrong on a distant server, what we feel is the helplessness of something being out of reach.
It's not surprising that technologies developed within army still talk the army language. But being so un-surprising, words and the worlds they carry along sneak into our worldviews, becoming normal, natural, invisible. Becoming just the way the world is, justifying and reinforcing the separation between user and developer, server and served, etc.
Looking at etymology, _deploy_ feels close to _display_. They share roots and gestures of making something visible and public, not to seclude it far away, but to make it accessible.
To deploy the padliography on a server, and make it accessible from a web browser, it's necessary to configure a way to make the communication between the application and the world possible.
In a server a lot of things are happening at the same time. When unfolding an application there it's important to reserve it a dedicated channel to talk with the outside.
There are various way to organize this communicational tangle: one of them is to use a reverse proxy. This system acts as a thin layer that intercept the messages that a server receives, delivering them to the appropriate application.
In order to make it work, every app that need to exchange data with the outside listen to a so called _port_, that is something like an address in the internal network of the server.
A reverse proxy listen to the external requests that come from the web, such as someone visiting the url `https://hub.xpub.nl/soupboat/padliography`, checks in its list of location and ports and finally finds out that indeed, requests to `/soupboat/padliography` are actually directed towards the port number 3000.
Copyleft with a difference: This is a collective work, you are invited to copy, distribute, and modify it under the terms of the [CC4r](https://constantvzw.org/wefts/cc4r.en.html).
