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. -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 >
