Fs2: Release 0.9.0 final

[mpilquist]

After a year of development, we are very close to releasing 0.9.0 final. Outstanding issues:

• #722 - We need to come to agreement on the API here and then adjust the PR accordingly
• Some more ScalaDoc

Does anyone know of any other issues or reasons not to release 0.9.0 final?

[mpilquist]

722 is in. I'm going to make another pass through the core ScalaDoc and then do the same for the io project. We also need to update cats and scalaz projects for the distinctConsecutive => changes rename. Other than those issues, does anyone know of a reason to hold off on 0.9.0 final?

[pchlupacek]

+1 to release

[mpilquist]

Opened #730 for final ScalaDoc edits and misc minor refactoring. Once that's merged, +1 from me for release. I'd like to at least hear from both @pchiusano and @fiadliel before going through with 0.9.0 final.

[fiadliel]

I just have one comment on API consistency (I was playing with the tcp code yesterday):
io.tcp and io.udp use an implicit AsynchronousChannelGroup, whereas io.file uses the default group. Wondering if we should make this consistent, though adding this will add a tiny bit more boilerplate to the file operations.

@pchlupacek any thoughts?

[pchlupacek]

@fiadliel I am not that good in nio.file api, but from the first look at https://docs.oracle.com/javase/8/docs/api/index.html?java/nio/channels/AsynchronousFileChannel.html I am bit confused, as this implies the open is using some ExecutorService and missing the typical callback pattern, whereas read and write are ok because they have just callback handler attached.

I wonder that this indicates that these are run on the Executor Service passed at open stage, and if so, I think we have to make these changes :

• Allow to pass ExecutorService somehow to "open"
• Use Async.start to fork any evaluation from the executor passed to open in read/write operations

I am not sure how we can reuse AsynchronousChannelGroup, to my knowledge this may be used only with TCP sockets.

If you think above is relevant, I think this has to go still to 0.9.0 and we have to make an issue for it to track it.

[fiadliel]

Okay - I looked back at the code, and we leave the callback thread using a Strategy as soon as possible. Those initial calls are run on the default AsynchronousChannelGroup, but the overhead should be very low.

Alternatively, we can, as you say, provide an ExecutorService - ugh, another implicit to define in advance. Looking at this, and considering we can't make the APIs follow the same pattern -- I'd say just stay with what we have.

[mpilquist]

After a brief review of AsynchronousFileChannel, I think we can leave API as-is.

[fiadliel]

:+1: then to release

[pchlupacek]

@mpilquist @fiadliel I still believe that these https://github.com/functional-streams-for-scala/fs2/blob/series/0.9/io/src/main/scala/fs2/io/file/pulls.scala#L54 and https://github.com/functional-streams-for-scala/fs2/blob/series/0.9/io/src/main/scala/fs2/io/file/pulls.scala#L62 has to have a way to pass in the ExecutorService somehow.

Specifically because I never found in our code to fork to another thread / or using F.start

[mpilquist]

@pchlupacek What do you think about adding an explicit, defaulted param to those 2 methods (and any methods higher in call stack) of type Option[ExecutorService] = None?

[fiadliel]

I don't think it needs an ExecutorService. That parameter to open appears to be for callbacks, and all callbacks end up going via file.asyncCompletionHandler, which uses F.start.

The main question here is whether the file opening itself goes onto a different thread; perhaps we could use F.start at https://github.com/functional-streams-for-scala/fs2/blob/series/0.9/io/src/main/scala/fs2/io/file/pulls.scala#L60

[pchiusano]

Am 👍 to release, assuming the file API stuff is settled. Can't believe it's finally happening!! 🎉🎉🎈

[pchlupacek]

@mpilquist @fiadliel I just switched to gitter so we can quickly finish this one.