Glad you liked the missive. I've saved a bookmark for future reference in case someone else comes in and asks (Comet usually comes up once a month or so).
For game development: Just screw IE. There's no way to do halfway decent graphics on IE, period. Go flash, or tell people to switch to firefox/opera/safari/comet. All 3 non-IE browsers are trying to speed up javascript. Opera 9.5 has a fairly spiffy javascript engine already, and both firefox and webkit are on the verge of shipping custom very smart and very fast VMs for javascript (tracemonkey for firefox, and squirrelfish for safari). Then there's V8, which you can see at work today in Google Chrome. It looks like V8, Tracemonkey, and squirrelfish will all be roughly as fast as one another (can you say meep meep?) - should do wonders for attempts to write games in canvas. Which brings us back to IE. F!*k IE. There's future hope though: I believe apple has rescinded copyright/patent claims on canvas, or they ran out, so in theory nothing is stopping IE from implementing them now - though as I understand it, Microsoft never expressed interest in supporting them. Microsoft is part of the W3C and evidently they have not been able to use their considerable weight there to stop the latest news at W3C. W3C's own home-grown XHTML 2.0 effort has effectively been mothballed indefinitely, and instead HTML5 has been adopted (HTML5 started as something from the WHAT-WG, which is a much less officious entity compared to W3C, and consists of the developers of Opera, WebKit (Safari), and Gecko (Firefox/mozilla). - e.g. the anti-IE league, and the main reason stuff like canvas has seeded so quickly to the other non-IE browsers) HTML5 has been dollied up with some lip service to XHTML but make no mistake: Few really expected the W3C to 'fold' to the clearly superior HTML5 work in progress. HTML5 includes Canvas (see http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html for proof). The question now becomes: Does Microsoft break even more from the W3C than they already have (remember, IE isn't exactly standards compliant). So far betas of IE8 indicate that Microsoft is seriously attempting to build a more compatible browser, so there's hope. Then again, armchair analysts (like myself ㋛) believe that Microsoft is still trying to prevent the web from becoming the host of virtually every computer app out there, in order to keep their own OS (Windows) in a safe market leader position. Microsoft's stranglehold on the web community by way of IE is one of the things holding web apps back, so there are plenty of pessimists who believe that the final version of IE8 will be a big disappointment. On Sep 7, 9:41 pm, markww <[EMAIL PROTECTED]> wrote: > Thanks for the excellent response, that was very helpful. Everything > makes sense, I was taking a look at Jetty and it seems easy to use for > what I want to do. I had been writing my own java nio server for a > class I was taking, it's cool to see how Jetty has taken advantage of > the nio stuff to support 'comet'. > > From a game development point of view, this is great because we can > wait for the server to send us data instead of constantly polling it. > > One thing that still seems to be missing is fast graphics support, to > actually render dynamic game data. I was working with the gwt canvas > intensively a few months ago, but was disappointed to find out that > IE's support for it was just horrible. Firefox and Safari (and > probably Chrome now) can do a decent job of rendering simple > primitives fast in a <canvas>. In fact, my iPhone could render > primitives faster than IE! I wonder if there is any development on > this (providing a fast canvas for direct pixel manipulation) by the > browsers. Right now it seems like the only way to do it is by using > Flash. > > Anyway thanks again for all those answers, definitely got me in the > right direction, > > Mark > > On Sep 7, 6:30 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > > > As you said, comet is a complex problem on the server side. On the > > client it's relatively straightforward. > > > Some issues: > > > 1) You either need an async webserver (such as something based on the > > fairly new java Simple, or the continuation support available in > > jetty), or you need an OS + VM combo which can handle tons of threads > > without a high overhead (the latest linux + the latest java 6 seems > > capable of this). Be especially careful if you've got a frontloader > > (such as Apache) that merely redirects to your actual java stuff. > > Apache, out of the box, will probably not use the new worked thread > > mechanism to communicate with the java server at the backend, and by > > default apache will start serving up 'busy' pages if more than 50 > > simultaneous connections are already running. You get to 50 very > > quickly when using comet. If this is your setup, google around for how > > to implement apache+comet+java properly. Personally I just run jetty > > only, no apache. > > > 2) The only safe way to do comet is to make a request from the client > > to the server, then the server returns NOTHING, not a single byte, it > > just waits, and then, once data is available, it sends it, and then > > closes the connection. In response, the client should open another > > connection and this whole song and dance number is repeated. The > > reason you can't just keep sending data across a single HTTP > > connection, is because the HTTP standard has no concept of 'flush'. A > > proxy or even the webclient itself (IE and Safari both do some limited > > caching, for example) will simply assume more will come very shortly, > > and never forward the data to the endpoint (your GWT app). In order to > > do this concept right, you need some sort of tracking number. > > > For example, imagine an IRC (chat) client using comet. You could > > simply assign to each chat line in the chat room an index number, and > > upon first connect, tell the client the last chat line index number > > spoken. From here on out, comet can be done by letting the client > > requesthttp://www.mychatserver.com/chats/line?idx="; + > > lastReceivedChatLineIdx++ - the server, upon receiving such a request, > > first checks if a line with that idx has already been said. If so, it > > is returned immediately (no comet). if NOT, it will not return an > > error, it will instead just wait and hold the connection open. Your > > servlet should register a listener of some sort with the central > > repository of chat messages, so it can wake up when the line with the > > given idx is actually spoken. You can't just ask for 'the next line' > > without a tracker ID of some sort, because in between receiving one > > line, processing it on the client, and opening another connection, a > > line might have been spoken. Without tracking you'd miss this line. > > > 3) Because proxies, webservers, and web clients all have HTTP > > timeouts, and they are all different, you should manually close the > > connection after ~50 seconds. In our chat example, you'd send back > > something like: [NO CHAT] to indicate to the client that in the entire > > 50 second span, the chat line with idx '1234' never came up so far. In > > response, the client should re-open the connection with the exact same > > request (gimme line 1234). > > > 4) For efficiency you may want to let the server respond with all > > relevant messages that have a tracker ID equal to or larger than the > > requested item. For example, in our chat app, if a client asks for > > message #1234, but on the server you already know that we're on > > message 1237 (a burst of rapid chats just recently happened, for > > example), then you should just send 1234, 1235, 1236, and 1237 in one > > go. You'll need a way to delimit each 'packet' of information in the > > response in this case. You could use JSON, for example. Or use a GWT- > > RPC call, though I don't know the specifics of making that work right > > with comet. > > > 5) Web clients internally have a 2 connections limit. This means that, > > for any given full server name, if there are already 2 open > > connections, and a third thing is requested from this server, the > > client will queue up this request instead of sending it. Once one of > > those 2 open connections is closed, it will send it. This is perfectly > > reasonable when all requests are handled as fast as possible, but in > > comet, the whole point is that requests are NOT handled as fast as > > possible. If you have multiple comet elements on a single web page > > (Let's say, a 'live' stock ticker AND a chat box, each running a > > separate comet connection), then you're out of connections, and the > > act of requesting a simple image in response to a mouse over or some > > such never goes through! > > > There are two solutions to this: > > > A) run your non-AJAX calls off a different server. For example, serve > > up images from img.yourhost.com instead of just yourhost.com. You > > can't do this for your comet connections, because those usually use > > AJAX calls, and those must go to the same domain as the web page (Same > > Origin Policy, wikipedia that if you don't know what that is). This > > won't help you if you have 3 separate comety things going on, and it > > won't help you if you have 2 comety things going on and a third thing > > needs to do a non-comet AJAX call (say, a standard GWT-RPC call). Then > > you need to go for the more complex option: > > > B) multiplex all comety stuff over a single connection. In other > > words, in one URL, you ask for EITHER the next stock ticker update OR > > the next chat line, and the server will respond with an indicator > > about what it's responding with, along with the content. In response > > your client should update the right widget, increase its index > > counter, and open another request of the same type (e.g. first you > > asked forhttp://myserver.com/comet/multiplex?ticker=1234&chat=5678), > > and your server responds with ([ticker:1234]AAPL: 170.12), then you > > should update the stock widget and right after that, start a request > > forhttp://myserver.com/comet/multiplex?ticker=1235&chat=5678). If you > > google around, 'cometd' is a system that has a framework for this > > multiplex stuff. I don't usually recommend cometd because for the > > majority of comet applications, you don't need to multiplex anything. > > > On Sep 7, 5:50 am, markww <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > Is there any 'comet' support via GWT at the moment? I'm not completely > > > up to speed with javascript / browser technologies, I believe comet > > > was the practice of having the browser keep a connection open to the > > > server so the server could push data to the browser whenever it > > > wanted, instead of the client browser always polling for new data. > > > > I'm not sure where GWT would fit into that as it would require some > > > logic server-side to work. Has there been any development with this, > > > where can I start? > > > > Thanks --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
