Open Ms2ger opened 9 years ago
I like to work on it. Some Questions before a start to work. Can help me someone, who work on it in firefox? I need to create many WebIDLs, is possible to create a folder like "indexed". To add all files inside this folder, for example http://mxr.mozilla.org/mozilla-central/source/dom/
cc @nox
Note that this is a pretty large project.
To start, you'll need to pick a backend and write Rust bindings for it. We were thinking SQLite4 or a LevelDB fork, probably the former.
@farodin91 We don't support subdirectories in dom/ yet; I don't think it's worth blocking on that.
@jdm Technically we just need to use reexports and it will work fine.
@Manishearth SQLite 4 suffers from a complete lack of bindings and my days are unfortunately made of 24 hours like everyone. :(
@Manishearth I can start with building an rust api for SQLite 4.
That sounds valuable :)
I like to write a binding in rust for SQLite. Any prefer which lib to use for it?
There is only one SQLite 4 :smile:
This is my first time to create an rust binding. Is there a small example for it
https://doc.rust-lang.org/book/ffi.html is a good start.
Please note that SQLite resides in a Fossil repository. I had started writing bindings for them, but it's very primitive for now. I can push that somewhere this week if you want.
I create an repo for this. I can start to work on it this week. Thank you.
@nox Any update on pushing the in my repo?
Sorry things were a bit hectic for me this week.
No problem
I start work on it https://github.com/farodin91/sqlite-rs. But currently my build script doesn't work to build sqlite4 on linux. I have no idea.
Any update to pushing in my repo?
@nox Any updates? It is also possible to use LevelDB with lib https://github.com/skade/leveldb.
I'm picking this up. Will start by writing SQLite 4 Rust bindings.
It seems there is no commit in SQLite 4 since 2015-08-15 and never had an official release, doesn't levelDB seems more mature (already used for indexeddb in Chrome) ?
That might just be because they intend SQLite 4 to be stable. SQLite is under active development, see https://www.sqlite.org/src/timeline . That might be SQLite 3, but I think the codebase is mostly shared.
@Manishearth What was the reason for choosing SQLite4 over SQLite3? If we are to choose SQLite3 instead, we can use existing crates that have already generated bindings for it.
4 is a kv store, 3 isn't. It's not just a version number.
We need a NoSQL db for IDB. Ironically, SQLite 4, is more or less NoSQL.
Here's what I discovered - someone has already written Python bindings for the SQLite 4 backend LSM DB. I wonder if I should do the same, instead of writing bindings directly to SQLite 4?
"Need" is a strong word, given an existing implementation in Gecko that uses sqlite3.
Per the conversation at IRC, it looks like there's only 2 viable alternatives:
SQLite4 is determined to be not mature enough for implementation now.
Spec link: http://w3c.github.io/IndexedDB/
I'm going to use SQLite3.
For database storage, we have two ways:
ATTACH
, we can lock on a per-object store basis and still do transactions that encompass multiple object stores.For indices, we also have two ways, the old Gecko way and a very fancy way that I would like to experiment with:
json
function in json1). We can then use that method to create an index on an expression for each IndexedDB index we want. We can make that function return NULL
when the key path is not found, and use a partial index to ignore such values.
Some interesting links:
This would also require a reimplementation of the serialised structured clone format described here (or something similar to it that we can store and introspect directly from SQLite).
We can't use ATTACH
for my first idea because its documentation states that it's not really robust when faced with crashes.
There are various things necessary on the Servo side, at least these three things:
Blocks #13942
hi @nox, do you know if the issue has advanced any further? Thanks!
It has not.
I am looking for a new task, and I thought this one was interessting. I have a few questions before I am comfortable claiming this issue.
As I understand it, IndexedDB should be implemented using a WAL to favor performance. This decision was taken in Gecko, and is seen in Chrome/IE. See change here. Despite the new 3.0 specification states it to be durable.
Since SQLite4 never got released, and SQLite3 not being the obvious choice, perhaps RocksDB is a valid option?
It is wildly used, and seems to fit indexeddb and servo quite well, i.e. fast and concurrent; embedded KV store. https://rocksdb.org/ https://rocksdb.org/docs/support/faq.html
It also has great rust bindings through rust-rocksdb used by e.g. TiDB. This would make it a lot easier to get a working IndexedDB.
Thoughts?
Seems like it's worth a shot!
@highfive: assign me
Hey @rasviitanen! Thanks for your interest in working on this issue. It's now assigned to you!
Just to provide some context on SQLite and other storage choices as they're being used in Gecko/Firefox:
Re: SQLite
Re: other options:
Re: selfish concerns on my part ;)
(Just filing as a placeholder.)