Sync API

[aldonline]

Would it be possible to provide a ( possibly restricted ) sync API to work with in-memory stores?

[antoniogarrote]

Hi, what kind of synching are we talking about?

Is the callbacks support not enough to sync changes in the local graph(s)?

Thanks.

[aldonline]

Right. I meant sync as in "no callbacks". I am writing some fairly complex logic that requires multiple dependent SPARQL queries and programmatic processing of results on top of an RDF graph. Having to deal with callback/promise hell makes the code explode in complexity pretty fast. Are you relying on some low level async APIs for basic SPARQL processing? Is Async only inherited from the persistence layer? You could provide an in-memory storage option that relied on simple data structures for indices, etc. for small in data size but complex in logic programs.

[antoniogarrote]

Got it, a synchronous API.

You're right about the possibility of building a synchronous version of the API for the in-memory store. That was the case for the first version of the library that was implementing a synchronous engine for the non-persistent store and an asynchronus one for the persistent one. However the public interface was still asynchronous because in the execution of queries you have to interact with asynchronus code: a parser in a load query, an AJAX request loading a remote graph, etc.

In the new version, I removed the asynchronous engine because it was increasing the complexity of the code a lot. It's really easier to mantain just a single asynchronous engine conected to the sync memory index/lexicon or the async IndexDB index/lexicon.

It would still be possible with some refactoring to provide an API that would accept both, a callback and return the value at the same time if the result is available, but it would only work with the in-memory implementation and certain SPARQL queries.