The current Capabilities doesn't express that so woudl I be right in
guessing that the permission is testing for these on the action? If so,
how could the graph capabilities help without assuming they are
guaranteed true (they be wrong! and as a security attack?)
On 08/05/15 21:50, Claude Warren wrote:
Sorry I missed this discussion. The permissions system recognises 4
actions: read, create, update and delete. thus distinguishes between
creating new triples and updating existing ones.
On Mon, May 4, 2015 at 4:35 PM, Rob Vesse <[email protected]> wrote:
Perhaps an EnumSet and a single method:
EnumSet<AccessMode> getAccessModes();
Assuming you can do bitwise operators on enum members in Java:
enum AccessMode {
Read,
Append,
Delete
};
Append sort of implies to me "add if new".
Is there a reasonable case for delete but not add (I can't think of one).
How about { Read, Append, Mutable }
Maybe Append => Add
Andy
So a Read/Write graph returns:
EnumSet.of(AccessMode.Read, AccessMode.Append, AccessMode.Delete);
A read only graph returns:
EnumSet.of(AccessMode.Read);
An append only graph returns:
EnumSet.of(AccessMode.Append);
etc.
Rob
On 30/04/2015 21:55, "Andy Seaborne" <[email protected]> wrote:
On 30/04/15 21:33, Claude Warren wrote:
So if a graph allows adding but not deleting how does it respond to the
isReadOnly() method?
My question was how important/frequent is that case vs the importance of
the question "is this graph mutable"? If it is rare, then designing
around the uncommon cases to disadvantage the common leads to a
confusing design.
isReadOnly() is false is the graph can change in any way.
Of course, we could have a default method in Graph that is
default boolean isReadOnly()
{ return !addAllowed() && !deleteAllowed() ; }
but a proliferation of methods isn't helpful either.
Andy
On Thu, Apr 30, 2015 at 9:13 PM, Andy Seaborne <[email protected]> wrote:
On 29/04/15 20:58, Andy Seaborne 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()
which leaves:
boolean sizeAccurate();
boolean addAllowed();
boolean deleteAllowed();
boolean iteratorRemoveAllowed();
boolean canBeEmpty();
Is it better to have
isReadOnly()
and not addAllowed(), deleteAllowed()
I can imagine append-only graphs but is it worth having two calls when
the
common case is read-only vs writable.
And if it is just
boolean sizeAccurate();
boolean isReadOnly();
boolean iteratorRemoveAllowed();
boolean canBeEmpty();
Should we just pull these up into Graph/GraphBase?
I have only found two uses of Capabilities in non-test, non-passing-on
cases. I didn't find any evidence of passing capabilities around.
One use of getCapabilities() in the isomorphism tester GraphMatcher -
it
needs sizeAccurate()).
One use in RDF/XML output; Abbreviated uses findContractSafe but it
prints
a warning if used and no one has asked about that in a long while so
I'm
guessing it does not happen any more.
Strangely - I can't find uses of iteratorRemoveAllowed() except in
tests.
Andy
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.
