On 29/04/15 16:04, Claude Warren wrote:
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).
Transactions aren't in the Capabilities interface.
Which aspects of the Capabilities interface? Some looks to be out of
date (findContractSafe); some are not the right question
(handlesLiteralTyping)
Andy
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.
