I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
I'm confused, is this just patch and apply patch?
But if you give this a cool name, it's a New Idea.
41–50 of 90 posts
I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
I'm confused, is this just patch and apply patch?
But if you give this a cool name, it's a New Idea.
Earlier quoted context omitted.
"client" doesn't mean web. Mobile apps, desktop apps, etc are all client-side apps that can run regular SQLite. Think of apps Spotify, WhatsApp, AirBnB, Uber, etc. Not to mention mail clients, web browsers, etc. Probably 90% of non-web clients are using SQLite.
I'm not sure about this, I may be exaggerating, but aren't all four apps you mentioned (Spotify, WhatsApp, AirBnB, Uber) built on Electron? So they'd be using SQLite in the Node portion as their storage. That's their "server side", not client side. For that portion (the locally-run mobile backend - the middleware) I guess it would make more sense... so I see what you're saying. [Edit: Of all 4 things - Maybe only Spo…
Earlier quoted context omitted.
I was going to say that. We really need a way to customise software at the source code level without forking.
You mean like #define + #ifdef?
It's not really possible to implement in the same way for many other languages, but something like this but for source code transformations (rather than bytecode, or machine code for compiled languages) is probably the kind of thing they're thinking of.
Mixin allows you to insert code into methods, modify calls to functions, read/write to local variables, modify constants, and a lot more in that type of vein. It is the way mods are made in the Fabric mod loader for Minecraft. I believe Forge also reluctantly added support for Mixin back in 1.16 or so.
Earlier quoted context omitted.
Two things: 1. There's almost certainly a port of Sqlite3 to WASM that would be more than glad to run in your browser. 2. I'd really love to know what applications fit in the "we had replication from the browser, peer-to-peer, I think we'd be living in a much more useful world" situation. We've had GunDB, IPFS, etc. that live in the browser for decades (and projects like Urbit), and the killer app just... doesn't see…
Heh. Well, #2, brilliant question. But no, I'm not thinking of anything as sexy as totally distributed filesystems. 15 years ago when I was into crypto and ran a bitcoin casino I would have had much bigger ideas for fully distributed DBs (which surely would have tanked and caused me ruin). Currently, I deal with a lot of site-specific software installations that run their own MySQL servers, some of which have unexpec…
SQLite itself is open source, but the last time I checked, its test suite remains proprietary. How does a "fork" like this be tested if everything stays working and compatible to upstream after the change?
There is a separate TH3 test suite which is proprietary. It generates C code of the tests so you can run the testing in embedded and similar environments, as well as coverage of more obscure test cases.
Earlier quoted context omitted.
One thing that's always brought up in these discussions, because it's worth bringing up, is the file format of the macOS image editor Acorn: https://flyingmeat.com/acorn/docs/technotes/ACTN002.html Personally I use it a bunch in mobile and desktop apps.
That's quite fun to know! Although, it's also funny that I downloaded the demo .acorn files on a Mac and the OS has no idea how to open them without searching the App Store. I feel like a JSON file would be more compact and easier to read, but wtf do I know. Harder to query, I guess?
> SQLite is used by thousands of software projects, just three being Google's Android, Mozilla's Firefox and Apple's iOS which between them have billions of users. That is a main reason why SQLite is so careful and conservative with all changes.
That's a great perspective. How well does the SQLite team work with them? How well does it work in production, especially if you need SQLite compatibility? And
> LumoSQL is a derivative of SQLite, the most-used software in the world. Our focus is on privacy, at-rest encryption, reproducibility and the things needed to support these goals. [...]
https://lumosql.org/src/lumosql/file?name=doc/project-announ...
I'm unsure what Phase 1 was about, or if there is a planned Phase 3, but seems to outline what they're currently aiming for at least.