←back to thread

275 points whatisabcdefgh | 4 comments | | HN request time: 0.003s | source
Show context
jll29 ◴[] No.45134255[source]
I love SQLite.

As a document _exchange_/_interchange_ format, what I prefer for durability is a non-binary format (e.g. XML based).

For local use, I agree SQLite might be much faster than ZIP, and of course the ability to query based on SQL has its own flexibility merits.

replies(1): >>45135099 #
thayne ◴[] No.45135099[source]
XML isn't great for exchange/interchange either due to security problems and inconsistencies in implementations. A big part of the problem is that xml has a lot of complexity, which leads to a bigger attack surface when parsing and processing untrusted data. And then xml entities are just inherently insecure, unless you disable some of their capabilities (like using remote files, and unlimited recursion).

That said, creating a format that can convey rich untrusted data is a hard problem.

replies(1): >>45135666 #
1. jdboyd ◴[] No.45135666[source]
Part of the problem though with saying SQLite instead of XML is a lot of things would lend themselves to XML in SQLite.
replies(2): >>45135727 #>>45135778 #
2. Ekaros ◴[] No.45135727[source]
Complex features are inherently complex. Say you want external resources or some scripts in document. No matter what storage format you use those are more surfaces. Problem is not storage, but what is done with information. And very often that is a lot and poorly thought out and even more poorly implemented.
replies(1): >>45136434 #
3. thayne ◴[] No.45135778[source]
Oh, I'm not saying sqlite is better than xml for data exchange. As mentioned in other comments, sqlite's security posture towards an untrusted database is problematic. My point is that xml has problems too.
4. thayne ◴[] No.45136434[source]
But most applications don't need those features. And if they do, that should be part of the application logic, with appropriate controls. Having your parsing library make arbitrary http requests is a bad idea.