[[ Cross-posting - let's try to reply to dev@commons. ]]

I guess this is mainly of interest to Commons RDF folks - but there's
some question baked in here on what to do with an experimental
interface. Note that the next incubator release of Commons RDF is
"0.3.0" - so we could still 'break' for a first Commons-release 1.0.0
(although it might still not be too nice to downstream users)


If we agree to add the jena/rdf4j/jsonld integrations to the Commons
RDF 0.3.0 release (I hope we do!), what should we do with the new
interface RDFParserBuilder ?

http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/RDFParserBuilder.html


I think it is very useful for allowing parsing of RDF with the
different backend libraries.
Note that I have not yet made the corresponding RDFWriterBuilder as I
would want it to mirror the same design.


However this was a bit experimental API design which has changed a
couple of times, so it's not really had much hammering yet. For
instance I am not sure there is much point in setting rdfTermFactory()
 as it was difficult with each of the implementations to effectively
use that factory.   (it would require deep change of the parsers).

It's also a bit up in the air if there's any point of the asynchronous
"Future" return type of .parse()  I like that it allows IO timeout &
cancelling, but that could in theory lead to thread pool fill-up if
incorrectly handled - all the parsers are effectively synchronous
single-threaded.


All the implementations use the base class AbstractRDFParserBuilder

http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/simple/AbstractRDFParserBuilder.html

(to handle the builder pattern and pre-flight checks)

But this mean they get a dependency on the 'simple' module - which
mean you would then always find two RDFTermFactory implementations on
their classpath (ServiceLoader might pick the 'wrong' one). Is that
OK?



Should we:

a) Delete RDFParserBuilder (and the implementations) for 0.3.0

b) Move RDFParserBuilder to package org.apache.commonsrdf.experimental
 or similar (allowing us to fully change it for the next version)

c) Same as b) - but also move RDFParserBuilder implementations to e.g.
org.apache.commonsrdf.jena.expeimental

d) Move AbstractRDFParserBuilder to api module

e) Remove RDFParserBuilder.rdfTermFactory()

f) make RDFParserBuilder.parse() synchronous

g) RDFParserBuilder is good as it is - release it in 0.3.0!


Views welcome!


-- 
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718

Reply via email to