Contenu de l'épisode
It's always DNS or CORS - and how your right brain is gating bad robots
Show Notes
-------------------------------------------------------------------------------------------------------------------------------------
00 - THE LOCATION TAG — SPEC TO DATASET TO GLOBE IN 48 HOURS
<b>The lead, and it's yours:</b> Wednesday afternoon Dave posted — "There is a new <b>locations</b> data set on the public datasets page... The db tables are still back-filling since I updated the db and aggregators to support the <b>new <podcast:location> tag format</b>. After a couple of days it should be mostly complete." He cc'd <b>@james, @alberto, @js</b> and then @DavidMarzalC. That cc list is the whole story — within 48 hours all four had done something with it.
@dave — the locations dataset post (20 Aug)
<b>The shipping trail:</b> web-ui <b>PR #608</b>, "add locations export to public data sets," branch <code>public_datasets</code> → merged to master the same afternoon. This is the first public dataset built on the new location tag format rather than the old one.
<b>Then somebody built the map.</b> By Friday morning <b>Alberto</b> had <b>radar.rss.io/#globe</b> up — a spinning globe of podcasts made in or about places on earth, drawn from the free dataset, most entries carrying full OpenStreetMap references. James put it in front of the OpenStreetMap community directly: "One for excellent people using @openstreetmap."
<b>James's review, and the two asks:</b> "This is so cool. Really shows the power of the location tag. The globe — would be nice to add <b>filters</b> to that (made in vs about). Or maybe just colour the dots differently? The next trick would be some <b>OSM lookups on the IDs</b> to work out what the places are."
<b>🔥 The flaw he found, and it's a good one:</b> "One drawback is that some people have chosen <b>'Queensland' as a location, which is 2.6x larger than Texas.</b>" — the granularity problem in one line. A location tag is only as useful as the smallest box someone is willing to put themselves in.
<b>Dave, on seeing it — and he is in Birmingham, Alabama:</b> "Wow, this is incredible. I already see a podcast from Birmingham that I didn't know was based here." ❤️ ❤️ <b>Dave, Friday:</b> "It's beautiful. I can see this data powering so many cool app and platform features."
@dave — Wow, this is incredible / Birmingham (20 Aug)
@dave — It's beautiful (21 Aug)
<b>The bug found by using it:</b> @alberto and @james noticed the <code>rel</code> property missing from the export. Dave: "That column is in there but I had to add it. I bet I left it out when I copied over the episode level response build code." Then: "I found the issue. I had made the change but <b>not deployed the new export script to production</b>. The 'rel' property should be in there now." Also confirmed: <b>channel-level only</b> in that dataset, not episode-level.
@dave — that column is in there but I had to add it
@dave — channel level only / rel now deployed
<b>😂 Community request of the week — @ChadF:</b> "we need someone to <b>add the FEMA regions</b> to this so I can add <b>FEMA region 3</b> to my podcast location." (Board: FEMA Region 6 is already broadcasting from the Heart of the Texas Hill Country.)
<b>Board questions:</b> does made in vs about want to be two tags or one tag with a rel? Do we want a recommended granularity (city, not state)? And is an OSM ID lookup something the Index should do once, centrally, so every app doesn't do it badly?
Podcast Index — public datasets
web-ui PR #608 — add locations export to public data sets
James on Mastodon — one for the OpenStreetMap people
-------------------------------------------------------------------------------------------------------------------------------------
01 - DAVE'S WORLD — THE MEMORY LEAK, THE REFACTOR, AND A WEBKIT WIN
<b>Podping / Iroh is eating RAM since DHT came out.</b> @suorcd and @alecksgates reported it; @ericpp confirmed on a Raspberry Pi 4: "It's strange because it <b>works fine for about a day and then ramps up the memory usage hard.</b>" Dave: "Previously it was v0.97. Maybe there was a <b>memory use regression when I removed DHT/DTT</b>. There were memory problems before that. I'll investigate."
@dave — memory use regression when I removed DHT/DTT
@ericpp — same on a Raspberry Pi 4
@dave — might have been an Iroh reload
<b>The target, stated:</b> "1 gig should be way more than I want it to need. I'd love it to run on <b>less than 500 MB of ram</b>. I'm in the middle of a PI pretty big refactor. Let me finish that up and I'll do this next on the list. Feel free to explore things yourself though if you are so inclined."
@dave — 1 gig should be way more than I want it to need
<b>And the suspect:</b> "I'm positive it's <b>QUIC</b>. I just don't know why." — with Dave asking what debugging would actually trace it. Board: this is last week's "DHT is out and podping is go" meeting its first bill.
@dave — I'm positive it's QUIC
<b>🏆 The WebKit fix landed.</b> Dave, Friday: "<b>It's merged!</b>" — a WebKit bug where a <b>CORS preflight hangs forever</b> if the server answers OPTIONS with valid Access-Control-Allow-* headers but a body that never terminates. WebKit was gating the preflight on the body finishing; Chrome and Firefox conclude it from the headers. So this was a <b>Safari-only hang</b>: fetch() never settles, bytes stream and get discarded until the page gives up. Fixed by concluding the preflight from status + headers as soon as they arrive. (Reported against bug 320657, reviewed by Youenn Fablet.)