On 20/04/14 19:04, Claude Warren wrote:
The security system does use the current implementations of Triple and Node
but it does have to convert them to SecTriple and SecNode.
I have several other projects in which I have to convert to/from base Node
and Triple implementations to something else. Mostly it is to do
serialization or compression. The RMI implementation and compressed graph
implementations are two that come to mind.
Doing RMI required converting from Node to a serialized Node and then back
again. I suppose changing Node from a class to an interface would mean
that the node factory implementation would have to do the conversion from
interface to concrete class where required. But I wonder, how much of the
current code would have to change to work with interfaces. The various
places that create nodes could continue to do so as they do now since the
nodes and triples they create would be implementations of the Node/Triple
interface.
Perhaps I misunderstand what is meant my "interface only" module. What I
would like to see is the addition of Triple and Node interfaces.
Am I missing something?
Claude
I'm assuming that Node at least and probably Triple/Quad are java
interfaces either way round. The question is the maven module structure
- whether there is a jena3-core with interfaces and the default
in-memory implementations, or whether there are two modules, one with
interfaces only (no impl, no tests) and one for the default implementations.
From a user POV, it makes no real difference (they use apache-jena-libs
anyway). From a system POV, it may be a better or worse choice - I
don't know ATM. A lot of the complexity of e.g. literals, is in the
datatypes, which is code.
It's hard (not impossible) to add new Node types currently.
ex1: A NodeGraph for graphs-in-graphs (N3 formulae).
ex2: In ARQ it would be nice to have a Node as a marker like "will be
bound at this point in the query execution" The ex2 Node extension is
"system-local" - it would never leave ARQ, and in fact it's just a
ephemeral item, just useful to reuse containers like Triple and Quad.
The ex1 extension is a new Node type that has widespread consequences.
A first-class array-type is another example.
ex3: Specialised implementation of Node, e.g. to carry around some
storage-specific (e.g. index into a datastructure).
That last one has to be done carefully in Jena because the fundamental
design is that Nodes can be be created and dropped into any graph etc at
any time. Inference depends on this as does query. In SPARQL, Nodes are
created which don't appear in graphs at all (e.g. results of expressions).
To do an ex3, the subsystem using them still needs to be able to cope
with Nodes it didn't create but it might wish to cache stuff in it's
Nodes. But having a map (LRU Cache) of "Node -> cached info" would mean
normal Nodes can be used. It moves the space usage around as extended
nodes are going to be larger than normal Nodes.
It has to be very, very careful about the contract for Node especially
the structure-based .equals. A URI Node is the same if the URI string
is the same string. Making .equals work on Nodes carrying additional
information is "interesting" :-)
Resource/Literal are tied to models/graphs and quietly copied if they
move across model boundaries. They are interfaces. They have had
separate implementations in the past but as far as I'm aware none exist
today. Maybe because its a lot of work to rebuild everything the core
implementations, maybe because it's just as easy to build on top of as
within the framework.
That goes more strongly for Node. Node is the realisation of an RDF Term
so it's hard to need it with exactly the right contract semantics.
What is it about SecNode that caused you to not use the current Node?
(Sorry - I'm not familiar enough with the security module architecture -
my bad)
Andy
PS I think I still agree with most of
http://mail-archives.apache.org/mod_mbox/jena-dev/201207.mbox/%[email protected]%3E
