Updating storage: large results sets trigger `Quota exceeded error`

[vemonet]

When running a SPARQL query with a large result set it can easily blow up the local storage size used by YASGUI utils storage npm package: https://github.com/zazuko/Yasgui/blob/main/packages/utils/src/Storage.ts

It gives a misleading message for non-savvy users: "Quota limit exceeded". It is not clear it's due to the local storage size, it could be interpreted as a response from the SPARQL endpoint (e.g. query planning freaking out)

Note the store npm package last release was 8 years ago, it is only available as commonJS, not modern ES module

Migrating to a more modern and scalable solution could be nice in the future (not a priority, but to keep in mind for future important changes):

• Use IndexedDB standard API instead of store, IndexedDB can store hundreds of MB of structured data in the browser with fast access, and reduces the amount of dependencies
• Introduce paging in the results tab to avoid overloading the HTML view, as mentioned in: Auto limit the number of results/pagination sib-swiss/sparql-editor#27

[vemonet]

Something that could be interesting would be to introduce streaming of the results when the endpoint streams the results (qlever, milleniumDB, jena and probably graphDB too).

For example, when running a query with a large result set in GraphDB built-in YASGUI:

1. first 1000 results are shown with a message a bit like "Still receiving results"
2. once the whole set has been received they print "Showing 1-1000 on 12345 results"

This should be possible on the client through comunica and https://github.com/rubensworks/sparqljson-parse.js, see w3c/sparql-query#323 for more discussions around streaming SPARQL results)