Moishe, thanks very much for the detailed answers! I think your design choices are fine, there is only one small suggestion I'd like to make:
> Connection info for channels (re: your first question) probably won't > make the cut for the first release of the API, but it is something I > want to do. Especially after writing the trivia quiz and having to do > the bookkeeping manually. One thing to note is that channels will > timeout after some amount of time (currently they're set at two hours) > so the model in trivia quiz will actually map to reality. But I hear > you that it's less than ideal. Channel timeouts are enough, as long as the application can be notified whenever they occur (e.g. via an optional POST to some configurable handler). I think this can satisfy all (or at least most) use cases. Support for such notifications is not a scalability problem, because the number of timeouts is in the same order as the number of channel creations. It's not enough if the only way the application can find out about the timeout, is to attempt sending a message through the channel. There may be clients that never receive a message, in which case their channel mappings will remain as junk in the datastore. So we're back to having to send periodic heartbeat messages, which is a needless complication. I hope this small tweak (channel timeout notification support) is easy enough to sneak into the initial release :) For bonus points, such notifications could be integrated with the TaskQueue system. This would be useful because the timeout handlers can then be retried if they fail, which is handy during read-only datastore periods. Of course this is not critical because a normal POST handler could spawn a task itself if necessary. > The second and third questions is also excellent. We don't have > definite plans to support a broadcast model for channels: we'll limit > concurrent connection per channel to something in the single digits, > primarily to support the case where a user refreshes their browser or > something. It is something I would like to do in the longer-term but > there are no definite plans around this. > > However, in the nearer term (but not for the initial release) I do > have plans to provide a 'send' method which takes a (potentially quite > large) collection of channel keys to send a message to. So the app > would need to keep track of which clients are interested in a > particular topic (clients a, b, c, d, e, etc care about 'cheese') but > then we'll be able to scale these fan-out scenarios better under the > hood and you won't need to make a ton of API requests to send the same > message to a bunch of clients. > > Finally, your third question: you've probably figured this out from > above, but the architecture right now encourages/enforces one channel > per client and one client per channel. We'll only allow one channel > creation per page and if you want to multiplex you'll need to handle > that yourself (by sending the right set of messages over the one > channel connection). Since we're not supporting broadcast, I think > this fits the model; if there are scenarios that you think need this > kind of multiplexing though please let me know. That's fine for me, as such a multichannel publish-subscribe system is indeed easy to implement on top of a working one-channel-per-client API. Support for batch-sends in addition to task-queue chains is a good fit for large fan-outs. I was expecting such an answer, and already planned to implement something similar anyway :) Thanks again! - Peter -- 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.
