I have no problem retiring FileGraph Capabilities is another issue. I have used it and it is used in several places in the contract tests where we have to know if the graph supports transactions and the like. I find it useful. In addtion the information containd in the capabilities is often not easily discoverable (if at all).
On Wed, Apr 29, 2015 at 9:45 AM, Andy Seaborne <[email protected]> wrote: > Claude's email about FileGraph prompted me to think for Jena3: > > What can be removed? > What can be simplifed? > > Even while keeping the current APIs, there is going to stuff that isn't > used, isn't used much, or even gets in the way. For maintainability, > effectively unused features are noise and risk needing to maintain > contracts that users don't actually use. > > Some things that come to mind in jena-core: > > FileGraph [*] > Capabilities > GraphTransactionHandler > > and with advocacy: > > RDFReaderF, RDFWriterF (with RIOT integration; caution for RDF/XML) > > Some places where interfaces don't seem to add anything: > > LiteralLabelImpl > > (actually the whole LiteralLabel thing is worth looking at - maybe we can > pull the whole thing into into Node_Literal itself) > > AnonIds - maybe leave in the RDFAPI (they cross the boundary) but > internall bNodes can be a couple of longs for their state (a UUID in other > words, not a UID). > > Andy > > [*] > In Java8, the app, or library code, could do this better as: > > update(()->{ > ... graph changes ... > } > > and update() does the on-disk backup stuff. > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
