# For Later **Single-tile weather radar** Using the RainViewer API for the radar and an OpenStreetMap tileserver for the map tile. Make a gif with a few frames of radar so we can embed it on the site. Zoomed out far enough that I'm not worried about opsec and with no marker for where I am in the tile. **Bring back file-times** Times are stored by whenwasit in a CSV files. I want to add the times to the bottom of the page again. I miss them. **Anlytics: For Fun** Seems fun, anyway, to try and design some weird anyltics system. Can we make it private enough that it can just be public? A friend says that the Analytics should be on a different system so that when it gets overhwlemed the main site can keep functioning. So, here's an idea: Just send it a stream of data through UDP? lmao. It can be on a separate VPS in the same datacenter *(so we can use a private IPv4)* and maybe we have a sort of heartbeat system to have a reasonable chance of not sending data to a dead service. TODO: - [] don't log referer if it's ourself - [] unstub Filesystem::reverse_resolve. ## Dirfiles These are files that match the name of the directory. The problem with a normal `index.html` is that you need the full path to get a semblance of what the file is for. This can be solved by matching the served file of a directory to it's name. For example, a `multimedia/` would have it's `index.html` renamed to `multimedia.html`. This does, however, make it harder to change the name/path of directories as you'll have to rename the dirfile if the directory name changes. What do you name the root file, then? You shouldn't have to match the webroot's directory name. Perhaps it should be configurable. I think for now we'll hard-code in `home.html`, though. ## Page-content uses templates Because writing the same outer-html for everything poses a few problems. I'll enumerate them for fun! 1) it makes keeping a consistent page style difficult. 2) making a style change or renaming a core-stylesheet would require going through and editing a large number of files. 3) helps separate the layout and content of the page. We're using the bempline templating engine. Not because it's the best or even really *that good*, but because I wrote it and I like it :) Page-content files will have frontmatter in the form: ``` --- key=value --- ``` blank lines and comments are acceptable. comments are lines starting with a `#` with these keys being common and defined. **title** (default: filename) the `` of the page == TODO: THE BELOW IS DREAMING == **og_title** (default: page title) the opengraph title of the webpage **og_type** (default: website) TODO: not currently implemented. everything is a website. **og_description** (default: none) a one or two sentence description of the page. ```html <!-- required tags. us an image requried? i do not have one.--> <meta property="og:title" content="nyble.dev | gone" /> <meta property="og:type" content="website" /> <meta property="og:url" content="https://nyble.dev/" /> <!-- not required but helps make better cards, etc. --> <meta property="og:description" content="gone for now. stepped out for a bit." /> ``` **path-offset** (default: none) remove a path component from the end of tree when displaying with the **path** pattern ### patterns **path** use this pattern with `path_link` and `path_name` to insert links to the directories below a page. ## Page content uses a weird kind of markup language It's mostly just HTML, but I'm tired of writing `<p>` so damn much. A block of text, a textblock, are consecutive lines that contain text. A double linebreak separates blocks. If a block starts with a `<` it's assumed to be raw HTML and will not be wrapped in a paragraph. You can escape any commands or annotations, both of which are described below, with a `\`. Like this: `\[`. You can also escape the slash itself, `\\`, or an opening greater-than, `\<`. ### commands **[@paragraphs off]** - stop wrapping text-blocks in paragrapha and just pass them through as is. this is useful for HTML. **[@paragraphs on]** - start wrapping text-blocks in paragraphs starting at the next line. ### annotations **[#element-id]** - give the paragraph for this text block an ID of `element-id` ## Atomizer!!! launch with the arguments `atomizer <awake.conf> <atom.conf>` known issues: - [ ] Relative links are not absoluteified - [ ] we should remove `<script>`. *(rather, we shouldn't put any in)* ## Date/Time Parsing Acceptable formats: - Date only: `2024-04-13` - Date/Time: `2024-04-13 02:56` - Date/Time/Offset: `2024-04-13 02:56 CDT` If no time is provided, noon is assumed. If no offset is provided, Central Time with the correct DST is assumed. Known timezones: `CST`, `CDT`