<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi guys,<div><br></div><div>so I think the High Level API is now in very good shape for another review. All the tests of the Autobahn Testsuite[1] now pass with the High Level API and the Low Level API, so it seems like it is full working (yay!).</div><div>I had to make a few changes to the API to correctly support fragmented Frames. There are still a few things to work on but I think the current code shows how the API will look like. The API was build with WebSocket JSR in</div><div>mind which will be build on top of it.</div><div><br></div><div>Find it as always here [2]. </div><div><br></div><div>Feel free to send feedback.</div><div><br></div><div>Bye,</div><div>Norman</div><div><br></div><div><br></div><div>[1] <a href="http://autobahn.ws/testsuite">http://autobahn.ws/testsuite</a></div><div>[2] <a href="https://github.com/normanmaurer/undertow/tree/websockets_high_level_api">https://github.com/normanmaurer/undertow/tree/websockets_high_level_api</a></div><div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>---</div><div>Norman Maurer</div><div><a href="mailto:nmaurer@redhat.com">nmaurer@redhat.com</a></div><div><br></div><div>JBoss, by Red Hat</div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br><div><div>Am 29.01.2013 um 07:00 schrieb Norman Maurer <<a href="mailto:nmaurer@redhat.com">nmaurer@redhat.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>Am 29.01.2013 um 00:43 schrieb Stuart Douglas <<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>>:<br><br><blockquote type="cite"><br><br>Norman Maurer wrote:<br><blockquote type="cite">Hey Stuart,<br><br>thanks for start the thread. I just finished the review of your changes<br>and have a few comments.<br><br>* FrameHandler:<br>I don't know if I like the fact that the same interface is used for<br>"assembled Fragments" (when<br>WebSocketSession.setAutomaticallyAssembleFragments(true) was used) and<br>not assembled Fragments (when<br>WebSocketSession.setAutomaticallyAssembleFragments(false) was used". I<br>think we really should either use another interface or do the assemble<br>work in an abstract implementation of the FrameHandler and just provide<br>abstract methods to implement that act on the "assembled Frame" then.<br>Also with the current interface design it is up to the user to detect<br>when the Frame is complete by check if he received all of the data. I<br>think we should make it easier and just tell the user when it is complete.<br></blockquote><br>Using an abstract frame handler to do the assembly sounds like a better idea.<br></blockquote><br>Please see my last email… I did go with an interface because so we can make it more performant by just do the assembly in our core.<br><br><blockquote type="cite"><br><blockquote type="cite"><br>Also I wonder if it is really useful to also get notified with the frame<br>content for other frames then Binary and Text. My idea would be that we:<br>- automatically respond to a Ping with a Pong<br>- automatically echo back the Close Frame and after that close the<br>connection<br>- Ignore Pong frames<br></blockquote><br>This is probably ok, there is however some info that I think we need to provide:<br><br>- So way of taking the idle time on the connection, so if the client has sent a ping the application has some way of knowing that the client is still alive.<br><br>- When the close frame is received the application should receive some kind of notification with any data that was in the close frame.<br></blockquote><br>I guess you are right.. Let me change this.<br><br><blockquote type="cite"><br>- Pong frames should definitely not be ignored, if the application has decided to send a ping frame they would want to be notified of the result.<br></blockquote><br>Again please see my last email.. The user is notified when a Pong is received. Just the content is ignored which is fine as the Pong will just contain the same as the ping.<br><br><br><blockquote type="cite"><br><blockquote type="cite"><br>The fact why I think we should just do this is that otherwise it is easy<br>for the user to make the whole thing messed up and so not be conform<br>with the RFC anymore. Do you think there are real use-cases for get the<br>content of those in the high-level API ? If not we may not want to<br>expose this at all.<br><br>* TextFrameSender / BinaryFrameSender<br>What about add an extra method to it which takes a FileChannel, offset,<br>length and SendCallback as parameter. So we could make use of zero copy<br>if a user want to send a file content in a frame.<br>Something like this:<br><br>void sendBinary(FileChannel, long offset, long length, SendCallback<br>callback);<br></blockquote><br>Sounds reasonable.<br><br><blockquote type="cite"><br>* WebSocketFrame<br>Should be renamed to WebSocketFrameHeader or something like this if we<br>keep it like it is atm.<br></blockquote><br>+1<br><br>Stuart<br><br><blockquote type="cite"><br><br><br>---<br>Norman Maurer<br><a href="mailto:nmaurer@redhat.com">nmaurer@redhat.com</a> <<a href="mailto:nmaurer@redhat.com">mailto:nmaurer@redhat.com</a>><br><br>JBoss, by Red Hat<br><br><br><br>Am 25.01.2013 um 02:25 schrieb Stuart Douglas <<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a><br><<a href="mailto:sdouglas@redhat.com">mailto:sdouglas@redhat.com</a>>>:<br><br><blockquote type="cite">Hi guys,<br><br>Last night Norman and I had a bit of a talk about what the high level<br>Websocket API should look like, and Norman came up with some<br>interfaces as a prototype.<br><br>So after looking at Norman's prototype I had a bit more of a think<br>about what our high level API should look like and this is what I have<br>come up with:<br><br><a href="https://github.com/stuartwdouglas/undertow/compare/websockets_high_level_api">https://github.com/stuartwdouglas/undertow/compare/websockets_high_level_api</a><br><br>I have been thinking about the use cases that we want to address with<br>the high level API, and when you would want to use the high level API<br>vs the low level XNIO API.<br><br>My thinking is that in general if you want to use async IO and deal<br>with message bytes as soon as they arrive this is covered quite nicely<br>by our existing low level API. The high level API should focus on<br>async operations involving complete messages, and blocking operations.<br><br>The JSR 356 implementation will just be implemented as a fairly thin<br>wrapper around our high level API.<br><br>Sending:<br><br>This is handled by (Text|Binary)FrameSender.<br><br>I think there are a few different use cases for the high level API in<br>terms of sending messages:<br><br>- Complete message async, with a callback on completion<br>- Complete message blocking<br>- Complete message blocking with Stream / Writer<br>- Fragmented versions of all of the above.<br><br>There is one use case that is not covered here, and that is sending a<br>partial messaged using async IO, as mentioned above the reason why I<br>don't think we should have this as part of the high level API is<br>because this is essentially what is provided by our low level API.<br><br>Receiving:<br><br>In terms of receiving I think that we should just have a single<br>handler type:<br><br>https://github.com/stuartwdouglas/undertow/compare/websockets_high_level_api#diff-5<br><br>This just receives complete messages. I think this is preferable to<br>having to register 5 different types of handler for every frame type.<br><br>These handlers just receive complete messages that are fully buffered.<br><br>In terms of fragmented messages I think we should provide 2 ways of<br>dealing with them, and have a setting that controls which one is in use:<br><br>https://github.com/stuartwdouglas/undertow/compare/websockets_high_level_api#L9R98<br><br>If this is true then we will just assemble the fragmented messaged<br>automatically and deliver it as 1 logical message. Otherwise they will<br>just be delivered as they arrive.<br><br>I would have liked to provide a way to receive messages via an<br>InputStream / Reader, to provide a way to get around fully buffering<br>messaged when using blocking IO, however I can't really think of a<br>nice way to do this.<br><br>What do you guys think? I know there is still some stuff missing (e.g.<br>we need a way to propagate auth and session information from the<br>original HTTP request).<br><br>Stuart<br><br></blockquote><br></blockquote></blockquote><br><br>---<br>Norman Maurer<br><a href="mailto:nmaurer@redhat.com">nmaurer@redhat.com</a><br><br>JBoss, by Red Hat<br><br><br><br>_______________________________________________<br>undertow-dev mailing list<br>undertow-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/undertow-dev<br></blockquote></div><br></div></body></html>