From 34bc2896b7408aa65f168759eff94b9fab15afd8 Mon Sep 17 00:00:00 2001 From: Ken Fallon Date: Wed, 25 Dec 2024 15:11:31 +0100 Subject: [PATCH] Cleaning up documentation --- Community-Content-Delivery-Network.md | 146 -------------------------- HPR-Directory-Structure.md | 69 ------------ 2 files changed, 215 deletions(-) delete mode 100644 Community-Content-Delivery-Network.md delete mode 100644 HPR-Directory-Structure.md diff --git a/Community-Content-Delivery-Network.md b/Community-Content-Delivery-Network.md deleted file mode 100644 index be2a056..0000000 --- a/Community-Content-Delivery-Network.md +++ /dev/null @@ -1,146 +0,0 @@ -# Community Content Delivery Network (CCDN) - -A location to track the deployment of the HPR Community Content Delivery Network, that provides a mirror network for our content. - - - Availability of HPR Content - -The HPR site has been traditionally been run on a single instance, which makes the project vulnerable. - -We have experienced several times where we have suffered from issues resulting from system outages, denial of service attacks, forced decommissioning, or increased costs. - -There is a clear need to host the content in multiple geographically distributed networks to increase reliability and redundancy. - -Applying a [Content Delivery Network](https://en.wikipedia.org/wiki/Content_delivery_network) in front of the provider addresses some but not all of these issues. - -These large vendor solutions provide free tiers, but the long term business model shows that these are not sustainable. - -Additionally the algorithms used would flag behavior considered normal for HPR contributors, as suspicious and would deny them access. - - -# Looking to the past - -At the dawn of the Internet, it was common for websites and services like DNS to be [mirrored](https://en.wikipedia.org/wiki/Mirror_site) by friends. - -This was for a long time not a viable option for HPR as the quantity of Audio Content was expensive to host and transfer, and was therefore beyond what a home user could reliably serve. - -Over time, in some locations members of our community have access to facilities that a few years ago would have been reserved for Internet Service Providers. - -If you are interested in helping hosting the HPR site and media, then please get in touch with _admin @ hackerpublicradio.org_ - - -## Requirements for Hosting - -- 24/7 Home Service -- fixed IP address -- unlimited bandwidth -- fast > 500mb/sec upload -- large > 1T of storage -- permission from your ISP to run a web server -- Contact information know to the Janitors -- Optional: [UPS](https://en.wikipedia.org/wiki/Uninterruptible_power_supply) - - \ No newline at end of file diff --git a/HPR-Directory-Structure.md b/HPR-Directory-Structure.md deleted file mode 100644 index 4a68aaf..0000000 --- a/HPR-Directory-Structure.md +++ /dev/null @@ -1,69 +0,0 @@ -# Goal - -HPR is dedicated to sharing knowledge and as such it should be possible for someone to have the files locally and play them on a mp3 player. - -It should be possible to post the entire backlog to someone and have them plug it in and for any media player be able to play it. Each episode has it's own "album" which corresponds to a directory. The directory structure is kept as flat as possible with everything related to show 9876 in a single directory `hpr9876`. This is the least common denominator, and in no way precludes web services, or other applications. - -We do however need to support other functionality so the _Episodes_ are kept inside of the `eps` directory, the _Hosts_ are in `hosts/`, and _Series_ are in `series/`. - -# Layers - -We get files from different locations. The source files are delivered by the hosts, some are generated by processing, and others are added by the Janitors that cleanup the show notes. - -All these are combined and end up as a complete entity, on one of the HPR [Origin servers](https://en.wikipedia.org/wiki/Upstream_server). - -From there is delivered made available via RSS, etc. - -## Upload - - - -In our worked example a host uploads a show recorded in an audio file in [flac](https://en.wikipedia.org/wiki/FLAC) format. -The show is about a bash script which they also attach. -They describe the show in show notes, and include an image of the output. - - -files will be distributed using the C - - -The show processing supports the building of this structure, - - - - - - - - - - -This is how the - -The `hpr_generator` places episodes are in `eps/`, - -Everything related to a given show should be in the - -We need to base our requirements on our own requirements and not those imposed by the IA. - - - -It should be possible for someone to `rsync` the entire site and store it locally for use with a file manager/or media player. - - -To make file management clear all files must begin with the episode number `hpr9876`. - -Supplemental files should be p - -If there is a possibility of a clash then we need to ensure that we manage that by avoiding upload names. - - -should layer ontop of that so `/path/to/disk/hpr/` is the root and then `eps - - - - -If any of the sites (The IA) require special treatment, then that's fine but it's a deviation from our structure. - -https://archive.org/details/hpr4230 → - -The directory structure imposed by IA is less than ideal when it comes to our requirements.