Marco, The permissions layer [1] is a separate module that wraps graph and model implementations with permissions checking. It can use Shiro (or whatever Fuseki uses).
Basically, it uses the dynamic proxy mechanism to intercept "interesting" calls to graph and model to filter out triples that should not be seen by the user. It operates at 2 distinct levels: You can limit user access to an entire graph/module or you can limit access to specific triples within the graph/module. I was recently wondering if anybody actually, (outside of the project I worked on, used it in production. I got an answer when I got a query about how to do some specific task from a company that was utilizing it for a number of implementations. Claude [1] https://jena.apache.org/documentation/permissions/index.html On Fri, Nov 15, 2019 at 11:24 AM Marco Neumann <[email protected]> wrote: > when you say as an afterthought you refer to shiro? to define permissions > functionality in a TTL configuration for high granularity would indeed be > nice. why not do it somewhat similar to how it's done in mainstream RDBMS > with SQL system tables? > > > On Fri, Nov 15, 2019 at 11:07 AM Claude Warren <[email protected]> wrote: > > > I would like to see the permissions functionality baked into the standard > > implementations rather than wrapped around as an afterthought. However, > if > > that can't be done or is just more overhead than we want when permissions > > are not in use then I would hope that we will continue to use interfaces > to > > define the objects in the API. > > > > I think we should also look at Rya (https://rya.apache.org) and Commons > > RDF > > (https://commons.apache.org/proper/commons-rdf/index.html) to see if > there > > is anything we can learn from them. > > > > On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn <[email protected]> wrote: > > > > > I would be very interested in discussing the high level Java API and > how > > it > > > could be simplified. > > > It might also be worthwhile to look into the overall package/jar > > structure. > > > This will help for both OSGi and JPMS support. > > > > > > Regarding the Java14/JPMS target, I assume this means that the Jena > code > > > can be compiled and run on a Java14 environment and/or used on the > module > > > path in a JPMS-enabled application (and *not* that all downstream > > > applications must use one of the newer Java runtimes). That is, would > the > > > compiler target and source still be Java8? > > > > > > Cheers, > > > Aaron > > > > > > On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <[email protected]> wrote: > > > > > > > I'd like to start a discussion on where the project might go longer > > term. > > > > > > > > This can be specific areas, overall design, about project processes, > > > > anything. > > > > > > > > If we are going to do a major change, Jena4, what preparation for > that > > > > can be done? (e.g. deprecation and signalling in Jena3, before the > > > > change happens). > > > > > > > > Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4 > > > > need not be that big - we can have Jena5 etc. > > > > > > > > I'll put some technical points in a separate email. > > > > > > > > I would put on the list: > > > > > > > > * How has the world changed? What should the project produce? > > > > * Target audience: for developers of Jena, while Jena3 is for users. > > > > * Target: Java14, JPMS. > > > > * Clear-up not easily done with perfect compatibility. > > > > * Simpler. There are APIs and packages entangled due to history. > > > > > > > > To the lurkers :-) > > > > > > > > Feedback and specific feature requests are welcome. But before you > "go > > > > shopping", you may wish to factor in that every feature needs effort > to > > > > do it. The better place to be is that an application can get what it > > > > needs to do, not whether the Jena system has every feature built-in. > > > > > > > > Andy > > > > > > > > > > > > > -- > > I like: Like Like - The likeliest place on the web > > <http://like-like.xenei.com> > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > > > -- > > > --- > Marco Neumann > KONA > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
