Еще 1 пример использования. С год назад писал простой сервис для коллективного обсуждения изображений pointoutapp.appspot.com/, там по полному используется Channels API, пользователи параллельно могут писать комментарии, добавлять точки обсуждений и тд.
Геты параметров юзать с по умолчанию
Вы не могли бы пояснить про что конкретно?
Хранить временные данные не буду в постоянном хранилище
Согласен — лучше данные пользователя хранить в memcache. Но при этом помнить что он может быть очищен в случае нехватки ресурсов.
>наружу из цикла наверное вынести?
согласен, пропустил очевидный косяк. исправлю.
>uuid?
непонятно в чем вопрос. channel_id это уникальный идентификатор канала, который должен быть стройкой. по нему создается канал.
>но на следующем шаге идентификатор вытаскивается из из параметров и игнорируется, а юзер «идентифицируется» только по нику
это уже грубый косяк. тем самым можно отправку подделать сообщения. исправлю.
>зачем, если channel api сам вызывает /_ah/channel/connected?
на этапе создания канала на стороне сервера мы создаем запись в базе о пользователе. тем самым блокируя создание такого же пользователя с одинаковым ником.
>непонятно в чем вопрос
>channel_id это уникальный идентификатор канала
я вижу что это. только генерится оно какой-то кривизной вместо нормального способа. help(uuid) почитайте.
>на этапе создания канала на стороне сервера мы создаем запись в базе о пользователе. тем самым блокируя создание такого же пользователя с одинаковым ником.
код сервера я вижу и он правильный.
вопрос в том, нафига перекладывать на клиента посылку серверу сигнала о подключении к каналу?
>вопрос в том, нафига перекладывать на клиента посылку серверу сигнала о подключении к каналу?
Теперь понял о чем Вы, поправил.
Спасибо за советы и исправления!
Простой чат с помощью Channel API на Google App Engine для Python