External Entities v3 compatibility

I started to review the code and it requires some time investment.
My first concern is: are there people using this module needing a port to xntt v3?
I even doubt I'll get some answers here... :-) but anyway, let's give it a try at least.

After reviewing the code, I think I'd better invest time on implementing a generic SPARQL storage client plugin (as a native xntt plugin) that would inherit form the QueryLanguageClientBase class. The problem is that I don't know much about SPARQL. I would prefer to not load entities using a REST endpoint (like it is in wikibase_external_entities) but rather use a SPARQL query to retrieve each entity data.
What I think we would need on the form would be:

• the SPARQL endpoint URL
• the prefix to use for id field (eg. "wd")
• the SPARQL query to load one or more entries with a "" placeholder to tell where to put ids. For instance:
  

  SELECT ?item ?itemLabel WHERE {
    VALUES ?item { <id> }
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  }

  where "" could be replaced by "wd:Q378619 wd:Q498787 wd:Q677525".

• maybe a mapping interface between Drupal field names and their corresponding SPARQL "prefix"? (filter mapping)
• maybe a placeholder list interface to associate <placeholders> in the query with other SPARQL queries used to retrieve the value when the external entity type is saved and avoid running such queries all the time (ie. cache the result and include it statically in the queries)

I don't know how complicated it could be to use regexp to insert filters in the SPARQL query. I believe though it should not be complicated to transform a SPARQL query into a count query automatically but please correct me if I'm dreaming! :-)

Thanks for the feedback @guignonv!

It must be possible to make the module so dynamic that queries can be created based on a mapping per field. For now the approach with getting the list view using Sparql to define the context, and simply fetching the records via REST works for the projects this module was created for. Also there is not really budget in these projects to cover the refactoring as the module now gives us pretty much what we need atm.

All this could change of course :)

Compatibility is another subject, this should be explored in order to keep this module usable.