For RMI I am only implementing a Graph. It may make sense to wrap model and dataset in order to achieve better performance (e.g. wrapping a TDB model/dataset may provide better performance than creating a model against multiple graphs on the client side), but for now it is just a Graph.
I did have to create a model wrapper for the Security code, but that is another kettle of fish. My plan is to complete the RMI implementation - 90% or so complete now, and add security to it (so you can restrict RMI access to specific graphs etc). Is there any issue with turning on the UUID inside the NodeFactory? I see that there is code for this. I would also like to see Node changed to an interface -- but that is another discussion -- I think it will keep the core cleaner as things like Node_Null won't pollute it. Claude On Mon, Dec 30, 2013 at 3:27 PM, Andy Seaborne <[email protected]> wrote: > On 29/12/13 20:40, Claude Warren wrote: > >> The RMI simply exposes an existing graph implementation on a remote >> system. >> >> The normal disclaimers apply but given the standard Jena configuration: >> >> NodeFactory.createAnon() uses UID to create an id that would be passed to >> the graph on the remote server where the anon would be recreated. >> >> The result is that both the client and the server have the same anon id >> for >> the blank node. >> >> Am I missing something? >> > > Only that UID are, strictly, only unique for the machine they are > allocated on. RMI etc can pass them around but they only safely identify > things on the same machine as their origin (they aren't long enough for > wider uniqueness). Its the UID user's responsibility nor to present them > on on a non-origin machine. > > Ideally, Jena3, I'd like to use UUIDs, and then store only two longs, for > blank nodes. They they are globally safe as well as being smaller. > > Out of curiosity - why do you need to extend to Model? Is there a > client-side implementation of graph and then it's just a case of wrapping a > Graph just like another other graph? Or am I missing something? > > > Another issue in parsing is keeping label->bnode mapping. Labels must be > matched to any previous use in the parser run. > > The RIOT parsers do not use jena-core UID generation for bnode ids. If > it's a map of label to node allocated, there is a growing data structure. > Something that we occasionally get reports of being a problem as the map > grows for very large parser runs. > > Instead, RIOT allocates a large number (122 bits of random) and xors it > with the label. So the internal id is calculated from the label and is > unique yet there is no growing data structure. > > Andy > > > >> Claude >> >> >> >> On Sun, Dec 29, 2013 at 7:43 PM, Andy Seaborne <[email protected]> wrote: >> >> On 29/12/13 16:58, Claude Warren wrote: >>> >>> Greetings, >>>> >>>> I have an initial implementation of an RMI based Graph that allows one >>>> JVM >>>> to access a graph in a different JVM. I hope to extend this to the >>>> Model >>>> level in the near future. I just wanted to know if anyone was >>>> interested >>>> in this project. >>>> >>>> Claude >>>> >>>> >>>> The perennial question ... >>> >>> How do you treat blank nodes? >>> >>> Andy >>> >>> >> >> >> > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
