buffer
usage grows, which means total memory usage won't exceed twice the size of
the heap since eventually garbage collection will clean both up.
>
> --
> - DML
>
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
7;s definitely beyond the scope of JEP 321 to
decide on that, it's something that we should keep in mind.
Regards,
James
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
the time to look at this, and sending your thoughts.
>
> On 08/12/17 00:30, James Roper wrote:
> > Hi all,
> >
> > I wanted to start a discussion about the use of Flow.Subscriber and
> > Flow.Publisher in JEP 321 (HTTP Client API).
> >
> > It seems that us
distinguish between partial and whole
> messages. The jdk8 implementation decoders/encoders accumulate
> messages and assemble them until the message is complete and then pass
> it to the Endpoint -- much more satisfactory arrangement.
>
> I cannot fathom the meaning or improvement of
you to provide an example of an application that is possible to
> implement in a non-back-pressured model and is not possible in the proposed
> WebSocket API.
>
> Thanks,
> -Pavel
>
> ---
> [1] https://github.com/reactive-streams/reactive-streams-jvm/blob/
> 3716ba57f17e55ec414aed7ccb1530251e193b61/README.md#goals-design-and-scope
> [2] One does not have to signal the message has been processed in order to
> receive the next message, if there are any. The signal is about
> handing over
> the message contents, not about the back-pressure.
>
>
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
On 12 February 2018 at 18:56, Chris Hegarty
wrote:
> James,
>
> On 10/02/18 07:38, James Roper wrote:
>
>> ...
>>
>> https://developer.lightbend.com/blog/2018-02-06-reactive-str
>> eams-ee4j/index.html
>>
>
> Regarding: https://gith
treams would make
correlation of those binary messages with the text header very difficult if
not impossible.
Regards,
James
On 12 February 2018 at 16:33, Pavel Rappo wrote:
> Hello James,
>
> Thanks for the comprehensive reply to Chuck's email. Now regarding your
> own em
possibility but please don't
> destroy the best client/server communication in the process. If
> necessary, create two implementations: WebSocketFast and
> WebSocketSlow.
>
> I'll go back to my cave now and pout about what has happened to my
> once fabulous WebSocket.
>
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
uld require a TCK
to verify it.
On 20 February 2018 at 08:41, Simone Bordet wrote:
> James (hi! :)
>
> On Fri, Feb 16, 2018 at 12:55 AM, James Roper wrote:
> > The question for me then is whether there is value in introducing an
> > additional higher level API (ie, a reactiv
x27;t see
>> why we should create one more of them. Would you rather have something
>> low-level, you could then implement your high-level API that is most
>> relevant to
>> your case?
>>
>
> You can see the reactive WebSocket API facade (abstracting different
> clients) in the Spring Framework:
> https://docs.spring.io/spring/docs/current/javadoc-api/org/
> springframework/web/reactive/socket/package-summary.html
>
>
> This is an example of just one way that WebSocket could be modelled.
> It appears reasonably straight forward, but restrictive in terms of the
> underlying protocol, not exposing partial messages for example,
> requiring an additional allocation of a message type for each message
> sent / received. I would expect that such a higher-level API could be
> implemented on top of the Java SE API without too much work.
>
> -Chris.
>
> [1] https://github.com/spring-projects/spring-framework/
> blob/master/spring-webflux/src/main/java/org/springframework/web/reactive/
> socket/WebSocketMessage.java
>
>
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
es, custom
close handling, very precise error semantics etc, and such a use case would
be well served by the current low level API.
Regards,
James
On 26 February 2018 at 22:15, Simone Bordet wrote:
> James,
>
> On Mon, Feb 26, 2018 at 4:37 AM, James Roper wrote:
> > On the topic of
WebSockets, we can draw some lines based roughly on what web browsers
> (which is the target application developer experience that >WebSockets were
> designed for) support as being high level, and what the WebSocket protocol
> allows beyond this as low level.
>
>>
>>
it is currently possible to use the `PATCH` method.
>
> Is `PATCH` sufficiently popular to warrant its own self-named
> method in the request builder?
>
> -Chris.
>
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
n the webrev are mechanical due to renaming, but
> > there are stability fixes and the API documentation has been
> > reorganized to improve readability )
> >
> > More information about the JDK HTTP Client can be found on the
> > networking groups page.
> > htt
rrectly, ensuring there are
no race conditions, ensuring that and end developer can 100% predictably
know that all errors will be handled in a predictable way, is not at all
trivial.
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
rkets using WebSocket, but not using Reactive
>> Streams.
>>
>> At this point in JEP 321, I do not want to increase the scope of the
>> project
>> to include a Reactive Streams interface for WebSocket. This is something
>> that can, and should, be considered separate to JEP 321. It could follow
>> in a future release if deemed appropriate, or not, but adding it at this
>> point
>> will add risk to JEP 321, which I am not willing to do.
>>
>> -Chris.
>>
>>
>
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
reams,
>>>> application developers will have an option where the answers are guaranteed
>>>> to be yes without the developer having to do any mapping themselves, and
>>>> the lines of code to do that will be one.
>>>>
>>>> Sure, if
hem to implement Subscribers and Processors
> (heck, I even have an IntelliJ warning telling me that I should not do
> that!), will cause confusion and be potential source of bugs - we all
> know non-blocking/async programming is hard.
>
> Thanks !
>
> --
> Simone Bordet
l JDK code
> base? I do believe it would help a lot of people out there.
>
> Based on my understanding, once I have signed the OCA, I should simply
> write an email to the group and request a sponsor to pick up this issue.
> Could someone help me with this?
>
> Thank you,
>
ources for
> learning/tinkering?
>
> Thanks!
>
> --
> Simon Roberts
> (303) 249 3613
>
>
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
the incoming request is application/json, text/plain, or application/xml,
in order to parse that correctly, you'll need to do things like
.matches("text/plain(?;.*)?"). Whereas, if you had a getMediaType() you
could just do a .equals("text/plain").
--
*James Roper*
*Senior
On Wed, 6 Jun 2018 at 21:03, Chris Hegarty wrote:
>
> > On 4 Jun 2018, at 03:48, James Roper wrote:
> >
> > ...
> >
> > +1 on variants of getContentType that give you either the media type or
> the charset parsed from the content type header. Without them, w
22 matches
Mail list logo
