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 discussion in process, but I find it very hard to follow a multithreaded discussion over email and I much prefer breaking things out early to more specifics. Shall I start capturing (or trying to) ideas, or is it too soon? ajs6f On Tue, Nov 19, 2019, 11:49 AM Bögershausen, Merlin Michael < merlin.boegershau...@rwth-aachen.de> wrote: > 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" <sorok...@gmail.com>: > 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 not begin flowing until a terminal operation is called > and then the data flows through the pipe without further action from the > caller. > > We should not even consider replacing Iterators with Streams and I did not > hear anyone suggest it. The suggestion I heard (and which I thoroughly > support) is to offer Streams alongside Iterators for their intended > purpose; pipelining computations. > > For example, consider a dataset backed by a remote SPARQL connection. > Suppose stream() is called on a graph from this dataset, and suppose > limit() is called on that Stream. Then in the right conditions a smart > implementation could push that limit upstream to become a LIMIT in the > SPARQL being sent over the wire. That's the real value of all those methods > on Stream. They aren't merely for developer convenience. A library like our > Iter would do for that. They are there to provide opportunities to classify > and manage the computations being pipelined. > > So Stream is very useful for its purpose, but not for Iterator's purpose. > As for crossing module boundaries, I haven't seen any problems with that > and I'm not sure what the objection actually is. In fact, refusing to > expose > Streams at APIs seems to make the whole thing rather pointless. > > ajs6f > > > On Tue, Nov 19, 2019, 10:06 AM Merlin Bögershausen < > merlin.boegershau...@rwth-aachen.de> wrote: > > > 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 uses streams. > > > > Another thing, I would like to see a graph view inside Fuseki UI, where > > the triples are visualized like in > > <https://www.w3.org/2018/09/rdf-data-viz/> > > I use such visualization whenever I explain the usage of our graph data > > model to my colleagues, whenever they have problems to develop SPARQL > > queries. Also, I feel that it would help our support team to see why > > the system performs unexpected steps. > > > > Merlin > > > > > >
