| ▲ | SQLite as an Application File Format(sqlite.org) |
| 43 points by gjvc 7 hours ago | 17 comments |
| |
|
| ▲ | rtyu1120 27 minutes ago | parent | next [-] |
| Bit unrelated rant but I'm still not sure why ZIP has been adopted as an Application File Format rather than anything else. It is a remanent of a DOS era with questionable choices, why would you pick it over anything else? |
| |
| ▲ | amiga386 5 minutes ago | parent | next [-] | | - archiver format to stow multiple files in one; your actual files (in your choice of format(s)) go inside - files can be individually extracted, in any order, from the archive - thousands of implementations available, in every language and every architecture. no more than 32KiB RAM needed for decompression - absolutely no possibility of patent challenges | |
| ▲ | tetraca 18 minutes ago | parent | prev | next [-] | | Because Windows can view and extract them out of the box without installing any additional applications. If it supported anything better out of the box I'd guess people would use that instead. | |
| ▲ | gus_massa 11 minutes ago | parent | prev | next [-] | | I think most format use "gzip" instead of "zip". | |
| ▲ | mikkupikku 18 minutes ago | parent | prev [-] | | It works well enough. What could, for instance, epubs gain by having another base format instead? |
|
|
| ▲ | renegat0x0 an hour ago | parent | prev | next [-] |
| I think I use SQLite like that (to some extent): - https://github.com/rumca-js/Internet-Places-Database For UI I use HTML, because it already provides components with bootrap, and everybody can use it without installation of any software. All data comes from a single SQLite that is easy read, and returns data. My database is really big, so it takes time to browse it, I wanted to provide more meaningful way to limit scope of searching |
|
| ▲ | stavarotti 3 hours ago | parent | prev | next [-] |
| Previously: https://news.ycombinator.com/item?id=23508923 |
| |
| ▲ | gjvc 2 hours ago | parent [-] | | five years ago. did you have a point? | | |
| ▲ | lmshn an hour ago | parent | next [-] | | The previous discussion usually has useful and interesting conversations that are nice to revisit. | | | |
| ▲ | wat10000 an hour ago | parent | prev [-] | | It’s a helpful link, not a criticism. | | |
|
|
|
| ▲ | jrochkind1 an hour ago | parent | prev | next [-] |
| Searched for this topic: > and is backwards compatible to its inception in 2004 and which promises to continue to be compatible in decades to come. That is pretty amazing. You could do a lot worse. |
| |
| ▲ | dist-epoch an hour ago | parent [-] | | Same as .zip, .xml, .json and many others. Doesn't mean that whatever the app stores inside will remain backward compatible which is the harder problem to solve. | | |
|
|
| ▲ | askl 30 minutes ago | parent | prev [-] |
| Somehow my first thought from the title was using sqlite as a format for applications. So like a replacement for ELF. I think this idea is both fascinating and horrifying. |
| |
| ▲ | trws 24 minutes ago | parent [-] | | I worked @fzakaria on developing that idea. It actually worked surprisingly well. The benefits are mostly in the ability to analyze the binary afterward though rather than any measurable benefit in load time or anything like that though. I don’t have the repo for the musl-based loader handy, but here’s the one for the virtual table plugin for SQLite to read from raw ELF files: https://github.com/fzakaria/sqlelf |
|
