On Thursday, December 2, 2010 9:26:38 AM UTC, Remigius wrote:In case you don't know, there's a sample app using channels:
http://code.google.com/p/dance-dance-robot/ http://dance-dance-robot.appspot.com/ Thanks - I'd heard of that but to be honest hadn't looked at the code as it's a Java demo (so the source is the somewhat usual twisty little maze of IDE config files and helper-factory-helper-shim-value-factory classes) - it looks like it makes a channel per player named after a unique key generated on the server when the client connected and then puts players into collections (games) and sends messages as updates to each player in a game. This reinforces the idea of a channel as "single consumer" (ie they don't make a channel per game and subscribe players to the game they're in) but there doesn't seem to much sign of clean up code (and there's a TODO comment in the code that catches the exception thrown by sending a message). Otherwise, if your assumptions are correct (i.e. a channel can only be connected by one single client), your strategy looks sound as far as I can tell. Even in the absence of a uniqueness requirement, it may be useful to be able to identify each client individually, at the cost of some house-keeping, of course. What I can't tell is how the quantity of opened channels scales, meaning if there's some drawback creating lots of channels. But if the channel API should be useful (which I hope), there should be no problems with using it for many clients. I hope so too... it's got to take less resources than polling so should work reasonably well but if, for example, the docs come out and say that the billing/quota for channels is not just "number/size of messages" but related to, say, the number of channels you've made and a channel doesn't magically expire for 90 days.. or if say there's a limit per app on the number of messages that can be buffered up without being consumed (so messages can get stuck behind a backlog of messages for channels that will never again be read) then I'd have to rethink my strategy. That's not to say that I expect either of the above to be the case, but just to point out that while I can figure out the fairly simple API details without docs, what I can't reliably discern is HOW the system is meant to be used and whether what I'm doing is fine-and-dandy or a demented perversion of the intended model... But thanks for the encouragement and I appreciate the pointers Cheers -- Tim -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
