On 15/11/2019 11:07, Claude Warren 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.
Certainly interfaces.
If the new API is not additions/modifications of the existing one, I
think we should have the current one and introduce a new API.
What would be the requirements for permissions-extensions? If not in
use, I'd like it to be invisible - security can also be in application
via request processing (the usual ACL stuff).
Clause also wrote:
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 am curious as to whether the permissions capabilities could be
provided at the Graph level on find/add/delete.
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.
Yes - are there specific aspects you have in mind?
We can not adopt CommonsRDF raw - the idea of just adding the interfaces
to existing Graph or Model unfortunately is messy with different methods
to do the same thing - an autocomplete nightmare.
We can provide an API module that is CommonsRDF over Graph.
Is there much code nowadays that uses CommonsRDF as its target? I have
always hoped we see the emergence of projects with algorithms that
target CommonsRDF for portability.
Andy
On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn <acob...@apache.org> 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 <a...@apache.org> 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
