Dear EG members,
we are still making progress on nio proposal (please see "nio" branch on
github [1]). Feel free to send any feedback you might have, or propose
any changes.
(nio branch has Publisher renamed to Source, but I'll use term Publisher
in this email to avoid confusion).
When we evaluated how other frameworks are using similar API, we noticed
that "public" APIs are usually Publishers, not subscribers. Thus we are
trying to remove all exposed subscribers from Nio proposal and replace
it by providing Publishers or returning Publishers from resource methods
/ nio body workers.
This has several consequences, derived from the stream nature of data we
are usually processing (request/response entities). For example, we have
to be sure that subscriber for any entity will get whole entity (not a
single byte can be skipped). That brings us to couple of rules for
framework provided entity publishers:
a) Publisher won't start publishing unless there is a demand. Demand
means subsciption.request(x) where x > 0. That means the sole presence
of a subscriber/subscription is not enough.
Reasoning: we want to avoid filling Publisher buffers or require ones.
b) there will be a subscriber limit - only single subscriber is allowed.
Reasoning: subscriber has to be certain that all bytes are consumed
(when you'd skip initial part of the message, you can throw that out.
Subscribing 2 subscribers with a guarantee that it will read complete
entity is "hard" (puts caching requirements on the publisher, which
might not be simple to fulfill). Also, when a user want's to have
another subscriber for logging, it would need to be a processor and do a
"chain" instead of a "tree". Another reason is that using one ByteBuffer
instance among multiple readers is not possible - we'd need to do some
kind of view and manage references.
Another rule might need to apply from application returned publishers:
When the publisher is created by the resource method, not based on the
request entity (i.e. handling HTTP GET method), it needs to be "caching"
or "lazy", something like [2] or [3]. I'm still not sure whether 3rd
party frameworks do commonly support Publishers similar to what was
described as a) and b) - if there is anyone who is more familiar with
flows, please let us know.
Any comments or suggestions are welcomed.
Thanks and regards,
Pavel
[1]
https://github.com/jax-rs/api/tree/nio
[2]
https://projectreactor.io/docs/core/release/api/reactor/core/publisher/ReplayProcessor.html
[3]
http://reactivex.io/RxJava/javadoc/io/reactivex/Flowable.html#cacheWithInitialCapacity(int)