Comments Inline
On Wed, Apr 9, 2014 at 10:49 PM, Rob Vesse <[email protected]> wrote: > Comments inline: > > On 08/04/2014 08:10, "Andy Seaborne" <[email protected]> wrote: > > >On 08/04/14 14:25, Rob Vesse wrote: > >> > >> In terms of specific collaboration opportunities I¹ve heard a few > >>different > >> ideas. I spent a bunch of time talking with Lewis McGibbney who¹s > >>involved > >> in Any23 about how Jena might make it easier for projects to share > >>common > >> functionality like RDF parsers. The current module structures are > >>something > >> of a barrier in this regard since we have multiple versions of some > >>readers > >> and they are quite closely coupled into some aspects of our APIs. > >>Improving > >> modularisation in the future (as I think we hope to do in Jena 3x > >> eventually) would make things like this easier for people. > > > >Agreed : we need something like > > > >IRI > >Non-RDF related common library (Atlas in ARQ currently) > >new core (graph API, datasetgraph) > >RIOT > >API > >SPARQL > >TDB (split into base, file, b+tree, main) > > This looks like the most sensible and concrete modularisation we’ve yet > come up with. To clarify are you thinking that the new core would be the > Node, Triple, Quad, Graph, Dataset APIs etc and then API would be the > Model and Ontology APIs. > > In which case +1000, that makes much more sense. > > Particularly then putting RIOT between the new core and the API so that we > don’t have two sets of readers and writers! > > I’d be interested to hear from Claude as to how the jena-security module > would fit in this, I guess it may need to be split into multiple modules > that build on each other and the other modules as appropriate. > > <claude> The security module - (first should probably be renamed permissions but in any case) just needs interfaces to work most efficiently. Currently it wraps Graph, and Model and provides a custom query engine that places access checks in the middle of the SPARQL calls. Given that. Under the new structure - as I understand it -- security would probably have to be broken into 3 sub modules: security-core (graph stuff), security-api (model stuff) and security-sparql (query stuff). Or perhaps I don't have the model/sparql separation correct in my head. Where does the query engine that is associated with a model go in the new structure? </claude> > >... > > > >A "maybe" is a module that is just the interfaces for graph, dataset etc > >etc. and have modules build from that but it looks to me like the > >difference between new-core and interface+core+mem is quite small. > >Having the in-memory implmentations around is necessary for internal > >working. > > I’m -0 on this > > <claude>Having interfaces in one place makes security easier. It is also easier to use the contract testing framework to verify implementations of the interface without cluttering the test package with concrete test implementations. This is a make it easier for the integrator/developer issue. +1 on this. </claude> > While it’s easy to do and relatively cheap in Java (as compared to .Net > where it is a PITA) and certainly the Sesame folks already take this > approach but I don’t see that there is much value provided. How many > people actually run completely custom Node/Triple/Graph/etc stacks? > > > > >And? Java8 so we can sort out iterators. > > > >Let's more actively discuss this. > > Sure though I think Java8 is maybe a whole other discussion. > > Another related discussion is moving to Git before we get started down > this route because doing this scale of refactoring would be horrible > within SVN. > > Rob > > > > > > Claude -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
