On 2022-06-27 17:36, Mike Ray wrote:
But for concurrent access by multiple Web visitors, we really need a transactional database.

There will no longer be multiple visitors accessing the database as only ever one person will be accessing it (more correctly them) at any given time.

When a change occurs, eg., when a new show is released. Say it's Dave.

 * Check the SQL file out of git
 * Run all the processing stuff we do to post a show, and update the
   database (on his local machine)
 * Export the SQL to a file
 * Check the SQL file back into git (which triggers a RSS feed for new
   commits)

---

All the mirrors, including hackerpublicradio.org, eg me

 * RSS feed shows there is a new commit
 * Check the SQL file out of git
 * Import it into my database of choice (again single user mode on
   local machine)
 * run the static site generator
 * write out the static pages to disk on
 * rsync files to the web server root directory and to
   `rsync.hackerpublicradio.org`
 * web server serves static pages to hackerpublicradio.org and
   hackerpublicradio.kenfallon.com

Then anyone with a pi, nginx, rsync and a fiber connection may just have a cron job that updates their site hpr.myprovider.example.com. Runs a cronjob that will every hour:

rsync -av --partial --progress anonym...@rsync.hackerpublicradio.org /var/www/html/


Now if you decide to run your own deployment, you are free to

 * RSS feed shows there is a new commit
 * Check the SQL file out of git
 * Import it into your PostgreSQL database
 * run `nikola build`
 * write out the static pages to disk
 * rsync files to the web server root directory
 * web server serves static pages to hackerpublicradio.raspberryvi.org

Eventually we will maintain a mirrors.txt file that will allow us to round robin the requests. So that when a visitor comes to DNS the requests can be round robined to hackerpublicradio.org, hackerpublicradio.kenfallon.com, hackerpublicradio.raspberryvi.org, andhpr.myprovider.example.com as they all will be serving the latest files.

We can only do this exactly because HPR changes (for the most part) once a day.

Am I explaining this correctly ?

--

Regards,

Ken Fallon (PA7KEN,G5KEN)
https://kenfallon.com
https://hackerpublicradio.org/hosts/ken_fallon
_______________________________________________
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Reply via email to