Re: WebSocket progress report
Hi Jonathan and Petr, I'm an Application Development Graduate Student at Illinois Institute of Technology and I'd like to get started contributing to Tomcat. If you have any tasks I can help out with please let me know. I'd even be happy to start with simple tasks in order begin to familiarize myself with the project and code base, such as writing or formatting javadoc or cleaning up white space. Cheers, Jeremy On Wed, Feb 8, 2012 at 8:41 PM, Petr Praus wrote: > On Tue, Feb 7, 2012 at 03:47, Mark Thomas wrote: > > > On 07/02/2012 02:23, Jonathan Drake wrote: > > > I'm one the three CS grad students working on WebSocket (along with > Petr > > > Praus). > > > > > > Just wanted to give an update on our progress, to let you know what > we're > > > working on: > > > > > > Adding support for fragmented payloads: > > > > Excellent. That and handling control frames are the biggest gaps right > > now in my view. > > > > > Right now, after receiving a frame, StreamInbound unmasks the payload > in > > a > > > WsInputStream and passes it up to the servlet via > > > onBinaryData()/onTextData(). > > > To support fragmented frames, we add an intermediate step: after > > unmasking > > > the payload, write it to a PipedOutputStream connected to a > > > PipedInputStream that we pass upward via onBinaryData()/onTextData(). > > When > > > the next fragment arrives, keep streaming data through the pipe. > > > > Piped[Input|Output]Stream are intended to be used with a separate thread > > at each end. There is currently only a single thread processing the > > incoming data. How do you propose to provide the additional thread? > > > > Ah, then it's different. I thought the client handler is running in > different thread. Then we'll probably need something different. > > > > > This has the advantage of also allowing us to stream huge payloads (RFC > > > 6455 allows for a 64-bit extended length field---way too much data to > > > buffer in memory all at once). > > > > That is certainly a requirement. However, there is more than one way to > > meet that requirement. > > > > Our initial idea was some form of a streaming API where the reader code > receiving the message fills a stream that's somehow connected to a client > code that would be consuming it. Hence the Piped[Input|Output]Stream stuff. > I also think the individual frames of a fragmented messages should not be > exposed to the client code. If I remember correctly, RFC specifies that its > up to the implementation to decide. What do you think? > > And, what are your other ideas for supporting huge payloads? > > > > > > > It has the minor disadvantage of breaking the ByteBuffer wrappers from > > > MessageInbound (we can still use them for small payloads if we buffer > > > fragments in memory) > > > > Could you clarify what is broken in what circumstances please. > > MessageInbound is expected to work providing that the message > > (regardless of how many fragments it is spread across) is smaller than > > the available buffer size. > > > > My expectation is that the current echo example would continue to work > > regardless of whether or not the messages were in a single fragment or > > multiple fragments. > > > > > I'm working on a patch that implements this...maybe a day or two. > > > > > > I'd appreciate any early criticism you may have---otherwise I mainly > just > > > want to prevent duplicate work by explaining what we're up to. > > > > Thanks for the heads up. > > > > The approach you describe isn't the one I had in mind, but that is a > > good thing. It provides an opportunity to compare and to take the best > > from both. > > > > It would be nice to have a test case or an example client for this. > > Unless there is an easy way to force a browser to fragment packets, I > > suspect a test case will be required. > > > > I'm not sure about other browsers but Chrome 16 fragments payloads so that > WS frames fit into MSS of the underlying protocol (TCP). So if I sent > string larger than roughly 1450 bytes from the client javascript, I got > fragments packets. Beware that "lo" device on Linux has by default MTU > 16436 so on localhost, the above value of 1450 bytes is much larger. > > > > Given that the implementation currently uses blocking IO > > Just to make sure, processor.read() calls are always blocking, right? I'm > somewhat confused by Nio/Bio/Apr in combination with this. As I understand > it, any of the three can be used at the user's will and so the processor > can be of type UpgradeNioProcessor. In that case the read on the underlying > socket is not blocking. So how come read on the UpgradeProcessor will > always be blocking? Can you shed some light on this? Thanks > > > > , my approach > > was going to be something along the lines of: > > a) read the headers > > b) call onBinaryData() / onTextData() > > c) make the payload available via WsInputStream until the end of the > > fragment > > d) read the headers for the next fragment > > e) make the payload
Re: WebSocket progress report
Hi Mark, I think I can work on the website. Is it mostly a css refresh you are speaking of? Are there new features that are needed? I like the look of the apache mina site http://mina.apache.org/ with the soft edges, gradients and nice spacing. Is there any php in the webpage source or is it just html? Cheers, Jeremy On Thu, Feb 9, 2012 at 10:04 AM, Mark Thomas wrote: > On 09/02/2012 15:07, Jeremy brown wrote: > > Hi Jonathan and Petr, > > > > I'm an Application Development Graduate Student at Illinois Institute of > > Technology and I'd like to get started contributing to Tomcat. If you > have > > any tasks I can help out with please let me know. I'd even be happy to > > start with simple tasks in order begin to familiarize myself with the > > project and code base, such as writing or formatting javadoc or cleaning > up > > white space. > > > > Cheers, Jeremy > > > Jeremy, > > In addition to the WebSocket work, there are ~100 enhancement requests > in various states in Bugzilla. You could also take a look at those and > see if one sparks your interest. If you have an interest in web design > the the Tomcat web site and documentation is long overdue an overhaul. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: WebSocket progress report
Hi Mark, >I suspect it will need more than that. The XLST will almost certainly >need some tweaks too. How timely, I'm doing xml transformations in my SOA class right now. >I prefer the work pid did on the Tomcat 7 index page for the ROOT webapp. I haven't used 7 yet, only 5 and 6. But I would agree on principle that the looks between these two entities should match. I should have some time this weekend to install tomcat 7 and take a look. Cheers, Jeremy On Fri, Feb 10, 2012 at 10:49 AM, Mark Thomas wrote: > On 10/02/2012 16:06, Jeremy Brown wrote: > > Hi Mark, > > > > I think I can work on the website. Is it mostly a css refresh you are > > speaking of? > > I suspect it will need more than that. The XLST will almost certainly > need some tweaks too. > > > Are there new features that are needed? > > I don't think so. > > > I like the look of the > > apache mina site http://mina.apache.org/ with the soft edges, gradients > and > > nice spacing. > > I prefer the work pid did on the Tomcat 7 index page for the ROOT webapp. > > > Is there any php in the webpage source or is it just html? > > The website needs to be static with the exception of the download pages > that use a little cgi. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Website refresh
Hi Mark, Check out the attached mockup of a possible web refresh. It would keep the same content. It adds a menu bar below the banner. I used color and styling from the tomcat 7 admin page so the looks match. hopefully it is something like you had in mind. Cheers, Jeremy Hi Mark, On 10/02/2012 16:06, Jeremy Brown wrote: > Hi Mark, > > I think I can work on the website. Is it mostly a css refresh you are > speaking of? I suspect it will need more than that. The XLST will almost certainly need some tweaks too. > Are there new features that are needed? I don't think so. > I like the look of the > apache mina site http://mina.apache.org/ with the soft edges, gradients and > nice spacing. I prefer the work pid did on the Tomcat 7 index page for the ROOT webapp. > Is there any php in the webpage source or is it just html? The website needs to be static with the exception of the download pages that use a little cgi. Mark >I suspect it will need more than that. The XLST will almost certainly >need some tweaks too. How timely, I'm doing xml transformations in my SOA class right now. >I prefer the work pid did on the Tomcat 7 index page for the ROOT webapp. I haven't used 7 yet, only 5 and 6. But I would agree on principle that the looks between these two entities should match. I should have some time this weekend to install tomcat 7 and take a look. Cheers, Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Website refresh
Thanks for letting me know Chuck. Please see the mockup image here. https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg Cheers, Jeremy On Sat, Feb 11, 2012 at 4:27 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Jeremy Brown [mailto:jjbosstrac...@gmail.com] > > Subject: Website refresh > > > Check out the attached mockup of a possible web refresh. > > The list strips attachments, so you'll need to post the image somewhere if > you want anyone other than direct recipients to see it. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail and > its attachments from all computers. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Website refresh
>I like the mockup. It is a step up from what we have already. Thanks, I think it's a good idea to match want Pid created for Tomcat 7. >I think there is some serious re-organising of the docs required as >well. I am happy to take a look at the reorganising if someone else (you >Jeremy?) is able to improve the look and feel (something that I known I >have zero talent for). I think we could start incrementally. Maybe just start the new css and the new header and static menubar for the base pages at first. How is the main content div generated for the main page? Do we have any insight as to what should be on the menubar? If we have any analytics for the site it could help us make the most utilized areas the most accessible. Can I get some access to look around, or is the source somewhere I can checkout? >I'm also happy to apply patches to the site and docs as you develop them. That sounds good since you are aware of the whole structure and I just got here. Pid >I've got mods to the site build that move it in the direction of the >7.0 index page. >If a partial patch is enough to get started I'll submit it. Do you mind sharing what you have started with us? If we can utilize any work you have already done that would preferable to doing it all over. Cheers, Jeremy On Sun, Feb 12, 2012 at 3:54 PM, Pid * wrote: > On 12 Feb 2012, at 16:57, Mark Thomas wrote: > > > On 11/02/2012 22:42, Jeremy Brown wrote: > >> Thanks for letting me know Chuck. > >> > >> Please see the mockup image here. > >> > >> https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg > > > > I like the mockup. It is a step up from what we have already. > > > > I think there is some serious re-organising of the docs required as > > well. I am happy to take a look at the reorganising if someone else (you > > Jeremy?) is able to improve the look and feel (something that I known I > > have zero talent for). > > > > I'm also happy to apply patches to the site and docs as you develop them. > > I've got mods to the site build that move it in the direction of the > 7.0 index page. > > I've not had/found the time to work through all the changes to make it > an effective or non-breaking change. > > If a partial patch is enough to get started I'll submit it. > > > p > > > On a related topic, we need to move to svpubsub by the end of this year. > > That means updating the site build script so it pulls in the docs from > > each of the latest Tomcat releases. Again, I am happy to get that > > working. The big advantage this gets us, is the ability to do instant > > updates to the website. > > > > Mark > > > >> > >> Cheers, Jeremy > >> > >> On Sat, Feb 11, 2012 at 4:27 PM, Caldarale, Charles R < > >> chuck.caldar...@unisys.com> wrote: > >> > >>>> From: Jeremy Brown [mailto:jjbosstrac...@gmail.com] > >>>> Subject: Website refresh > >>> > >>>> Check out the attached mockup of a possible web refresh. > >>> > >>> The list strips attachments, so you'll need to post the image > somewhere if > >>> you want anyone other than direct recipients to see it. > >>> > >>> - Chuck > >>> > >>> > >>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY > >>> MATERIAL and is thus for use only by the intended recipient. If you > >>> received this in error, please contact the sender and delete the > e-mail and > >>> its attachments from all computers. > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: dev-h...@tomcat.apache.org > >>> > >>> > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Tomcat web site UI update
>That is a comment that the layout needs to be >cleaner (a comment I agree with). I agree too. I tried to create a cleaner layout and I posted a mockup for all to see and voice their opinions. https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg I'll leave it to Mark, Konstantin, Wesley and whomever else to let me know when it is reasonable to move forward. Cheers, Jeremy On Tue, Feb 14, 2012 at 11:40 AM, Mark Thomas wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 14/02/2012 16:21, Christopher Schultz wrote: > > Mark, > > > > On 2/13/12 5:28 PM, Mark Thomas wrote: > >> On 13/02/2012 20:11, Christopher Schultz wrote: > >>> > >>> IIRC, Pid did a bunch of work toward that end and it was > >>> ultimately vetoed > >> > >> Reference please. That is not my recollection at all. > > > > Markmail remembers: > > > > http://markmail.org/message/og235cbvrdluiejg > > That isn't a veto. That is a comment that the layout needs to be > cleaner (a comment I agree with). From a style point of view it is a > big improvement. > > Mark > > > > >> My recollection was that pid started down this road but hasn't > >> found the time to finish it, or at least get it to a state where > >> enough was complete that it could be committed. > > > > Konstantin liked it for the ROOT webapp, but not the Tomcat main > > site. Same with Wesley Acheson. > > > > -chris > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPOpx3AAoJEBDAHFovYFnnxEIP/Rvhm+UYlVq5enUzWlPbLmWC > ZPXcduolPXTVwU2jpIZpSw020677h92kq3dWFL7JSlKNhuHK2C/fS0iI9YYY0Xp/ > L9qYf7fvzSvzka7wUFJxFXLwPX6uoDAFwFtr+KSBmus3S206elkCCtILB/z06itA > VE31NVqOmXqLq7ZrqsE+4oxzqdkiJV1Cl1uKfR+O0LRJJ39Yl5+LyjThRDWdandC > JoWDnJhz/rAWC473X4NWh9q0LXK04uiufvHN3qtq1tbjl2YQ2tkEdcgJilXXCOF/ > NgcnvBlWw5R6o9w2Hm7X5xu6YAi8FS1sdWZ5QAihMud23pxT4KCUlK7DSzz2v3Yt > vWXEWpbaOD7kFa2c1Wj8dxED4q9ZB8UZZfBkCpG/AGXA1W1DrygPOePkRCNMzBSe > L7JWBU5CBJ6avlSnEFMXZIgXg/iVf0bGJUSZr+nL9auoDmJwyN46/HyDeK9ucWyn > O6TTzCFgCrcI01k7sVt3vrmtX2/JcvF2O0XMGRYTD/6trFWg96eA7NeOab7Rq90S > S6HcEFWGgM52/SibK49yc1J1oQvwNFHzZ2FNINMLBHRI4FjnbLbwxqF8IcZtKs+5 > YlbpiiXz+9LIUS8negOTTStXJFqmGaauYMZmIDf7JxFfxozCCQsayifzn+62STrX > bx3sI4uobJxVqoNNe++B > =F97+ > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
