Thanks for this! I'd like to drop a note of explanation here, for future readers:
Yes, anyone can "just create a LinkedIn account." However, quite a few people across the globe are trying to decrease their online surface area. While many of us (myself included) just have a password manager filled with thousands of entries and 32-character passwords, some folks are not comfortable living that way. I also find myself unsubscribing from or filtering emails from these services at least once a day, so I can appreciate why many folks are increasingly trying to simplify their lives by eliminating SaaS logins.
Even without creating a LinkedIn account, one could fill in a dummy URL to satisfy the JavaScript validation and submit the application. However, we chose not to do this because of how the YC application itself is structured. The submission requirements are intentionally strict (60 second founder video, <3mins demo, very specific questions, etc.) and subverting the application process feels antithetical.
Having the option to opt out of the LinkedIn field is greatly appreciated.
We did try to get WASI to work, but ECL itself doesn't yet target it. It fell down on missing set/longjmp support in wasi-libc. We haven't tried WASIX yet.
There are other approaches than the one we've taken so far, and we're still experimenting. But for the current demo, we're quite happy with Emscripten. The entire Wasm ecosystem feels pretty darn magical. :)
Endatabas team here. Thanks for clarifying why this post was marked as a dupe.
We recently released our Beta, including a live in-browser demo built on Wasm. It seems the OP noticed our release somewhere, but didn't mention the Beta or the Wasm build in their new post.
You are welcome! All credit goes to the Github gist someone posted. I fully agree with you, this explains what Apples magic GUI does behind the scenes.
txtai looks cool! It's not obvious from the title of the post, but Endatabas isn't really comparable to SQLite in this way. Endb is a cloud-native columnar immutable database with separated storage and compute. Only the SQL grammar is SQLite-inspired.
That said, the significant dialect difference is that Endb's JSON-like documents are strongly-typed. One of the places the Endb SQL dialect diverges from SQLite's is typing. In this respect, SQLite is "more schemaless"... at least at the level of weakly-typed scalars and nested JSON (since JSON supports a diminutive set of types).
While acknowledging you're only addressing the Copeland paper (and not Endatabas, where the OP found it), here's the Endatabas solution to this problem:
wonder how it compares with postgre temporal table or just adding a `entity_history` somewhere. Or the timeline data is more intrinsic to the DB design on this one?
The temporal columns are intrinsic to Endb, but they are completely optional. By default, Endb queries run as-of-now, which then return the same results one would expect from a regular Postgres database.
Postgres temporal tables can't make Postgres natively aware of time, so temporal queries tend to be awkward, even if you want the default as-of-now result.
There are temporally-aware databases (SAP HANA, MySQL, SQL Server), but they all treat time as an additional concept layered on top of SQL-92 via SQL:2011. It's difficult for a mutable database to assume immutability or a timeline without becoming another product.
`entity_history` and similar audit tables aren't comparable at all, since they don't even involve the same entity/table, which means all querying of history is manual. Indexing of audit tables is at least a bit easier than the SQL:2011 temporal solutions mentioned above, though.
In all these cases, schema is still an issue that needs to be resolved somehow, since (again) incumbent relational databases assume a Schema First approach to table layout. Endb is Schema Last and allows strongly-typed nested data by default.
The Endb demo is pretty recent, and explains all of this in more detail, with examples:
Yes, anyone can "just create a LinkedIn account." However, quite a few people across the globe are trying to decrease their online surface area. While many of us (myself included) just have a password manager filled with thousands of entries and 32-character passwords, some folks are not comfortable living that way. I also find myself unsubscribing from or filtering emails from these services at least once a day, so I can appreciate why many folks are increasingly trying to simplify their lives by eliminating SaaS logins.
Even without creating a LinkedIn account, one could fill in a dummy URL to satisfy the JavaScript validation and submit the application. However, we chose not to do this because of how the YC application itself is structured. The submission requirements are intentionally strict (60 second founder video, <3mins demo, very specific questions, etc.) and subverting the application process feels antithetical.
Having the option to opt out of the LinkedIn field is greatly appreciated.