The DOM API has "levels", but I find that really terrible and not something to duplicate.
.import() construct into a duplex stream. it's a quick implementation. i think it can be done with better performance, but needs some more tests: https://github.com/rdfjs/sink-to-duplex
@/all rdfjs/data-model-spec#158 a month later still have 2 approvals, I think we may need to adjust our practice and maybe require at least 2 approvals and wait one full week for objections. After that merging.
Any objections to me merging that PR tomorrow, unless 3rd person approves and merges it already today.
:+1:
did we define how many people need to approve it?
I think we agreed on 3 but based on my experience since then 2 seems more realistic, I also think that not fundamental changes can get merged after a week and for more significant ones we should give 2 weeks to make sure everyone had chance to review.
https://www.w3.org/2019/Process-20190301/#general-requirements
Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report. An editor must be a participant, per section 5.2.1 in the Group responsible for the document(s) they are editing.
.toJSON() and .fromJSON() methods. for the last option i always fear that we start defining a new serialization and people start to use it outside js.
@elf-pavlik We've used them at one point, but passing the data to the render thread (IIRC JSON.stringify would output a large [{termtype: x, value: y}, ...] string -> put it in.postMessage -> call JSON.parse (which are now POJSO compliant objects) -> Iterate new Statement(new S, etc)) created a larger hit than benefit for mobile devices (in rdflib the render thread also has to perform indexing again). The same problem occurred with a POC when reading and writing data via indexedDB
Some more liberal thoughts; from a performance perspective, using a SharedArrayBuffer with HDT formatting would seem the end-game. Libraries can transform the buffer representation to a spec compliant one, skipping the cloning algorithm altogether (though possible still needing to iterate to instantiate)
https://html.spec.whatwg.org/multipage/structured-data.html#safe-passing-of-structured-data mentions
Platform objects can be serializable objects if they implement only interfaces decorated with the [Serializable] IDL extended attribute.
So I don't think we should conflate it with JSON which does stringify and parse. Recently added DataFactory#fromTerm and DataFactory#fromQuad already can upgrade Serializable objects to full RDF/JS interface (pretty much adding .equals() method). I would like to reconsider having something like toSerializable() method which would make it symmetric and provide clear way to do round trip. I think this would also come helpful for Dataset so WebWorker (including ServiceWorker) can fetch data and pass whole dataset to the main thread. IMO one never should need to run any RDF parser on the main thread.
[Transferable] objects https://html.spec.whatwg.org/multipage/structured-data.html#transferable-objects but I think we still have to support [Serializable] since they seem to have broader set of use cases.
@elf-pavlik That's a tough question to answer from pure reasoning, I unfortunately don't currently have a good setup to test it. When using Transferable the sender loses access to the object, so the worker can't just pass its own index if it wants to reconcile data from future requests (it'd need both). The worker would have to make a deep copy of all the indices and pass those copies to the render thread which can replace them in-memory.
When the UI-related state is in the store then those changes will have to be communicated back to the worker as well or else that state will be lost (assuming using a postMessage -> worker reindex -> tranfer cycle could easily take 20ms)
