Hi Google team,

I know the Channel API is not yet official, but a lot of its code is
openly visible and I've already been playing with it. There are a
couple of questions which I'd like to ask before fully committing to
it. They are related to the high-level intended usage patterns for the
API.

For starters, let's summarize how the Trivia Quiz app, whose source
code Moishe recently released, works. It creates one channel per user
id. Users are divided into shards, and the list of active (online)
users is maintained in the datastore. An user is removed from this
list when a message is sent to his channel, but his last action was
more than 1 hour ago.

Let's call Trivia Quiz's approach "Scenario 1" - i.e. each user opens
exactly one channel, and the app maintains a list of online users. For
each message, the app has mechanisms to decide which users should
receive it, and sends it to their channels. A variation of this
approach is to assign channels based on session id, instead of user
id. Anyway, here comes my first question:

Q1: Will the Channel API provide mechanisms to ease the tracking of
online users in "Scenario 1"? Maintaining the online list manually
TriviaQuiz-style kinda sucks (a lot) - it requires either periodic
polling from each client to signal that it's alive, or periodic keep-
alive messages from the app to each open channel and watching for
exceptions. IMHO most of the Channel API adopters will be only
interested in messaging online users, so there should be more
efficient ways to do that.

Moving on. Let's suppose that all users of our application are
interested in stories about cheese. So we hand each of them the same
channel token, derived from the word "cheese". The application does
not maintain any user lists, it simply sends a message to the "cheese"-
channel whenever a new story pops up, and expects each connected
client to receive it. Let's call this approach "Scenario 2".

Q2: Is "Scenario 2" intended to work with the Channel API? Even with
very large numbers of online users, all listening to the same channel?

Finally, let's extend our cheese-application with support for stories
about broccoli. Some clients will be interested both in cheese, and in
broccoli. So the app will give those clients two channel tokens - one
derived from "cheese", the other from "broccoli". Let's call this
"Scenario 2++".

Q3: In "Scenario 2++", will the Channel API be smart enough to
multiplex multiple open channels for one client, over a single Comet
connection to the GTalk servers? As we all know, maintaining more than
one physical long-poll Comet connection is unreliable, as all browsers
limit the number of simultaneous requests per server.

Thanks in advance for any answers!

-- 
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.

Reply via email to