[[ 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
