I'm not sure how unusually slow Bruno's $work is. It's the same where I am
and I know of plenty of other places in academia or government that look
similar schedule-wise.
To be clear, I am not arguing for Java 8 beyond Jena 3-- instead (I think)
I'm agreeing with Bruno that we might want to think
No problem! Streams and Iterators have confused me myself, but luckily Andy
and other folks helped straighten me out.
Andy, you've given a nice list of potential discussions and others have as
well. My meta-question is when do we want to switch to tickets for this
process? I don't want to smother
Seems like I've got the wrong feeling from early messages, revisited Andys Post
missed the "additional provide" part, sorry.
Am 19.11.2019 16:48 schrieb "A. Soroka" :
I think there may be some confusion here about Streams and Iterators.
Streams are not and were never intended to be a replacement
I think there may be some confusion here about Streams and Iterators.
Streams are not and were never intended to be a replacement for or
equivalent to Iterators. Iterators are a source of elements. There is no
further complexity. Streams, on the other hand, are pipelines of
computation which do
Hi,
To the Stream discussion: Streams should not be passed beyond module
borders. In my personal view not even beyond scopes, because the
exceptions thrown by an already terminated stream can be misleading.
Every user can feel free to use the StreamSupport class whenever the
application code
On 17/11/2019 23:07, Claude Warren wrote:
I am a bit concerned about Streams.
I am working with some large scale streams from stored objects in another
project and keep coming up against stack overflow issues when attempting to
convert merge them or convert from iterators. Perhaps I have
On 16/11/2019 23:55, Bruno P. Kinoshita wrote:
What perspectives do other people have on the landscape?
My company is pretty slow in updating its stack. They have Java8 only now (and
an isolated pod with java 5 or 6 for a legacy app I think). Not aware of any
java9+ yet.
I think for Jena 4
I am a bit concerned about Streams.
I am working with some large scale streams from stored objects in another
project and keep coming up against stack overflow issues when attempting to
convert merge them or convert from iterators. Perhaps I have not done it
correctly but the iterator approach
This is a bit of a brain dump ...
== DatasetGraph
Graph Triple, Quad, DatasetGraph in a single API place.
== Graph - SPI
Graph - add a few navigation operations to make writing system directly
on Graph easier - though still not as rich as the Model API, and avoid
much of the object churn.
On 15/11/2019 09:49, Marco Neumann wrote:
I believe future versions of Jena need to be a bit bolder, this while
maintaining basic API features and design choices for compatibility in a
maintenance release.
Agreed - there should be a system which is production-stable, certainly
covering up
>What perspectives do other people have on the landscape?
My company is pretty slow in updating its stack. They have Java8 only now (and
an isolated pod with java 5 or 6 for a legacy app I think). Not aware of any
java9+ yet.
I think for Jena 4 we could go with Java LTS os LTS-next (assuming
On 14/11/2019 22:39, Bruno P. Kinoshita wrote:
Maybe an upgrade on Fuseki UI? Last I checked it was using Backbone JS, with
dependencies bundled in the code. Even though the NPM/JS ecosystem is a bit
more complex, we could probably upgrade it to
Maybe worth starting as a new UI, write
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
On 14/11/2019 20:08, Aaron Coburn wrote:
I would be very interested in discussing the high level Java API and how it
could be simplified.
Let's take API discussion to [API] and not loose the other points.
It might also be worthwhile to look into the overall package/jar structure.
This
thank you for the link Claude, looks indeed like a very useful addition to
a standard implementation. In particular when combined with an enhanced
admin UI I would think.
Marco
On Fri, Nov 15, 2019 at 1:33 PM Claude Warren wrote:
> Marco,
>
> The permissions layer [1] is a separate module that
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
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
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
first of all Andy thank you for your leadership as PMC chair of the Apache
Jena project, the PMCs and the Jena community. I do believe Jena as a
technical project is in a good place to be considered as the development
choice for any possible RDF related effort at this point.
Over the last 20
Maybe an upgrade on Fuseki UI? Last I checked it was using Backbone JS, with
dependencies bundled in the code. Even though the NPM/JS ecosystem is a bit
more complex, we could probably upgrade it to
- use a framework- specify dependencies in package.json (good to monitor for
security issues)
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
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
22 matches
Mail list logo
