On Tuesday, August 11, 2020 6:42:32 PM CEST Paul Bjorkstrand wrote: > If I may suggest, use CompletableFuture instead of Future. IMO it is a more > natural API, and helps to steer people away from using the blocking method > Future.get(). It's hard enough to ensure features are developed properly > for a multithreaded application without adding in thread-blocking "async" > operations. (This assumes you were intending to use Future as a means of > denoting an asynchronous operation.) > > A side benefit: you may be able to get away with not building a custom > pipeline API, and just make methods that return a CompletionStage. The > benefits of this are questionable, but it may help with prototyping or > implementing under the covers.
Thanks, Paul! Completable just got lost somewhere. I had CompletableFuture in my mind as I'm quite happy with what we have in Commons Messaging Mail: https://github.com/apache/sling-org-apache-sling-commons-messaging-mail/blob/ master/src/main/java/org/apache/sling/commons/messaging/mail/MailService.java Regards, O. > -Paul > > > On Tue, Aug 11, 2020 at 8:07 AM Bertrand Delacretaz <[email protected]> > wrote: > > Hi, > > > > On Tue, Aug 11, 2020 at 2:11 PM Oliver Lietz <[email protected]> > > > > wrote: > > > ...I would like to discuss new API and modules for content analyzing and > > > processing... > > > > I think it's often useful to be able to chain such things in a similar > > way to Unix Pipes. > > > > Which might speak for an API like > > > > FilePipeStatus s = FilePipe. > > > > .withProcessor(grep) > > .withProcessor(sed) > > .withProcessor(antivirus) > > .withInput(someInputStream) > > .withOutput(someOutputStream) > > .start() > > > > WhereFilePipeStatus provides access to the completion Future and to > > the processing report, which might also be modeled along the lines of > > standard output / error. > > > > Just my 2 cents - but I think a pipeline model can be useful here (and > > we already have something named Sling Pipes) > > > > -Bertrand
