While we are at it I would like to see that restriction that requires Grahp.getStatisticsHandler() to return the same instance every time removed. It makes proxies much more difficult.
On Wed, Apr 29, 2015 at 8:58 PM, Andy Seaborne <[email protected]> wrote: > On 29/04/15 18:17, Claude Warren wrote: > >> I use the following: >> >> addAllowed() is used by contract tests to determine if triples can be >> added. Also, permission system sets this based on the users permissions. >> canBeEmpty() is used by the contract tests to determine if the deleteAll >> methods should return an empty graph. >> > > When is this ever false? Inference graphs? > > (This is not used in the current codebase as far as I can see) > > deleteAllowd() same use as addAllowed() >> iteratorRemoveAllowed() -- this is handy to know before the remove is >> attempted. >> > > This isn't honoured everywhere IIRC. You're only looking in jena-core. > > sizeAccurate() -- this is used by the contract testing to determine if >> delete and add should alter the number of records reported. I am also >> looking at adding some hash joining capabilities and knowing if the sizes >> are accurate may make a difference. But that is all future stuff. >> > > FYI: > https://github.com/afs/quack > > These I don't use and can see being removed: >> >> findContractSafe() -- I don't know what this one means and have never used >> it. >> handlesLiteralTyping() -- This was used but obviously sine all graphs now >> have to support literal typing this can be removed. >> > > and presumably not addAllowed(boolean), deleteAllowed(boolean) > > (I find the boolean form unhelpful because they don't say what triples can > and can not be add/deleted.) > > so let's try removing: > > addAllowed(boolean) > deleteAllowed(boolean) > findContractSafe() > handlesLiteralTyping() > > > Andy > > >> On Wed, Apr 29, 2015 at 4:14 PM, Andy Seaborne <[email protected]> wrote: >> >> 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. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
