Pull to refresh

Comments 13

Еще 1 пример использования. С год назад писал простой сервис для коллективного обсуждения изображений pointoutapp.appspot.com/, там по полному используется Channels API, пользователи параллельно могут писать комментарии, добавлять точки обсуждений и тд.

Для тех кому интересны исходники github.com/buger/PointOut.
Загружаете картинку и делитесь полученной ссылкой с другими.
Channel API всё также потребляет до 3 секунд процессорного времени на подключение, как полгода назад?
К сожалению да. Учитывая что выдаются 100 последних сообщений суммарно тратится порядка 14 сек.
при создании канала, а не подключении.
Геты параметров юзать с по умолчанию значением буду я. Рушится будет программа моя иначе по каждому чиху.

Хранить временные данные не буду в постоянном хранилище я, черевато ресурсами ибо это.

Минус кармы хотел я, как Йода писав поэтому.
Геты параметров юзать с по умолчанию
Вы не могли бы пояснить про что конкретно?

Хранить временные данные не буду в постоянном хранилище
Согласен — лучше данные пользователя хранить в memcache. Но при этом помнить что он может быть очищен в случае нехватки ресурсов.
>q = OnlineUser.all().filter('channel_id =', channel_id)

истинно четкие посанчики знают еще про matcher prospective search api.
>channel_msg = json.dumps({'success':True,«html»:outstr})

наружу из цикла наверное вынести?

> channel_id=str(random.randint(1,10000))+str(datetime.datetime.now())

uuid?

>Только учтите, что обязательно посылать уникальный id канала клиента, чтобы верно идентифицировать клиента в приложении.

но на следующем шаге идентификатор вытаскивается из из параметров и игнорируется, а юзер «идентифицируется» только по нику

>Надо добавить отправку запроса в обработку события socket.onopen():

зачем, если channel api сам вызывает /_ah/channel/connected?

>Последним этапом будет запуск c помощью сron-а обработчика, который будет выделять все записи из модели пользователей OnlineUser, у

проспектив серч с временем прохунания это сделает проще.
>наружу из цикла наверное вынести?
согласен, пропустил очевидный косяк. исправлю.

>uuid?
непонятно в чем вопрос. channel_id это уникальный идентификатор канала, который должен быть стройкой. по нему создается канал.

>но на следующем шаге идентификатор вытаскивается из из параметров и игнорируется, а юзер «идентифицируется» только по нику
это уже грубый косяк. тем самым можно отправку подделать сообщения. исправлю.

>зачем, если channel api сам вызывает /_ah/channel/connected?
на этапе создания канала на стороне сервера мы создаем запись в базе о пользователе. тем самым блокируя создание такого же пользователя с одинаковым ником.
>непонятно в чем вопрос
>channel_id это уникальный идентификатор канала

я вижу что это. только генерится оно какой-то кривизной вместо нормального способа. help(uuid) почитайте.

>на этапе создания канала на стороне сервера мы создаем запись в базе о пользователе. тем самым блокируя создание такого же пользователя с одинаковым ником.

код сервера я вижу и он правильный.

вопрос в том, нафига перекладывать на клиента посылку серверу сигнала о подключении к каналу?
>вопрос в том, нафига перекладывать на клиента посылку серверу сигнала о подключении к каналу?
Теперь понял о чем Вы, поправил.
Спасибо за советы и исправления!
Sign up to leave a comment.

Articles