sqlite3 is older than the current type system usage trends. There were strongly typed languages back then, but it was for niche/research uses. People wrote in C. That's why it provides those little helpers and it's not absolute about types. I bet if it was written with say, Ocaml it would be strongly typed from the get go.

That's a nice way of looking at it...but I'd argue that if the intent is to be a "bag of bytes" you don't want to imply it's anything but that. Simultaneously if you want it to be typed, it seems less than ideal to have them front and center and then be wishy-washy with them.

I'm not a polemic, but I believe compromise on things like this corrupts conceptual clarity. Choosing one or the other would help learners quite a bit I'd think. I understand engineering tradeoffs are the enemy of such thoughts though.

I want everything typed but I'm not a polemic. Sqlite has chosen to be a raw bytes database with some metadata and checks on top to help you type those bytes if you want. Application logic can have control over the data's type validity. Adding types to sqlite3 is just another layer of logic that might even duplicate effort.

Let's scratch that itch!

In src/build.c:1046 the parser checks the validity of an object (table, index, view or trigger). If writable_schema=ON it skips the error checks in the CREATE TABLE statement. Dangerous but convenient. If the schema is corrupt, these checks wouldn't catch it.

This is awesome! The loose type system is my main complaint about sqlite...I know it's a matter of opinion, but it always struck me as a really strange choice. I just like being confronted with errors as fast as humanly possible.

I wish there was some way to check how much code directly interfacing with sqlite before this was effectively asserts on the structure of what's returned.

All that being said, the arguments for the loose type system are linked from that article https://www.sqlite.org/flextypegood.html . They don't particularly move me, and their points seem to be ones that would more effectively be addressed in other ways. But again, I understand it's more of a project choice than something objectively good or bad.

Also, fun quote:

Because of a quirk in the SQL language parser, versions of SQLite prior to 3.37.0 can still read and write STRICT tables if they set "PRAGMA writable_schema=ON" immediately after opening the database file, prior to doing anything else that requires knowing the schema.

Currently working up the motivation to understand that quirk. Just kind of sounds like a fun random happenstance.

Yup, sounds like a tool for a job, I'll publish the poptea crate once it has clean tls client code and TOFU is optional and then I'll make PR for sic tools.

I suppose gemtext is plain enough, or you would like some formatting as well (like in readability case)?

Here's the relevant code

Basically, it fetches the url,

• if it's a pdf it tries to get plain text output,

• if it's html it pipes it to a rust binary that uses a "readability" algorithm library to get the content as plain text (here's the code)

  also, it calls w3m to get formatted text output from that also.

So my thought was that if it's gemini, not http, we can get the gem mark with a small tool like fetch_remote_content.

Could you expand a little bit on the archiving of the links? How does that work with http at the moment?

My plan is to make a lib for both client and server, and then create mini binaries to demonstrate the usage.

So at some point it will be totally possible to either use it in script, or write your own rust program for that purpose.

At the moment it only handles 20 response code (sounds like that's enough for archiving purpose, but a lot of cleaning up should be made).

Kudos on your project :) Could we use it to archive sic submissions with gemini urls? It's done for http only at the moment.

I had no idea there was a non-pathologized name for this. I love it.