Как Gmail работает в Opera?

Я хотел бы знать, как Gmail (или кто-то еще) выходит на Opera.

Вот то, что я знаю до сих пор из своих экспериментов.

  1. Он не использует тег event-source, который не работает в Opera. 10,51.
  2. Он не использует iframe, который отображает вращающийся пульсатор и занятый курсор мыши.
  3. Он не использует responseText в xmlhttprequest, когда readyState = 3, что, как известно, не работает в Opera.

Я попытался посмотреть, как это делается в mibbit и etherpad, и обнаружил, что они оба используют длинный опрос.

Награда

Награда достается тому, кто может сказать мне метод лучше, чем «источник события» для потоковой передачи комет Opera, или как gmail выполняет потоковую передачу (или длительный опрос, если он это делает).


javascript gmail ajax opera comet
person Unknown    schedule 17.04.2010    source источник

Ответы (4)


arrow_upward
9
arrow_downward

GMail использует BrowserChannel (Документы | Source), который включен в Библиотека закрытия.

  • @fileoverview Определение класса BrowserChannel. BrowserChannel
  • имитирует двунаправленный сокет через HTTP. Это основа
  • Gmail Chat IM подключения к серверу.
person Jason Hall    schedule 19.04.2010
comment
т.е. closure-library.googlecode.com/svn/docs/ Подумайте, то, что вы на самом деле ищете, находится здесь: закрытие -library.googlecode.com/svn/docs/ поиск pollResponse_ и getNextChunk_ :) - person hallvors; 19.04.2010
comment
Вы можете быть более конкретными? Я чувствую, что дал достаточно щедрое вознаграждение, чтобы оправдать ответ, а не просто ссылку на гигантскую абстрактную библиотеку. - person Unknown; 20.04.2010
comment
Что ж, я как бы чувствую, что это следует оставить Джейсону, поскольку он дал исходный указатель на Closure, и я просто пошел немного глубже ... Глядя на этот исходный код, кажется, что он действительно использует асинхронный XMLHttpRequest с таймаутом, который отвечает для опроса responseText и обработки входящих данных. Opera не запускает несколько событий readystatechange при поступлении фрагментированных данных (что Firefox делает в основном по счастливой случайности - насколько мне известно, нет стандарта или документации, требующей этой реализации). Поэтому вместо ожидания нескольких событий readystatechange они используют тайм-ауты. - person hallvors; 20.04.2010
comment
@hallvors, да, я обращался к Джейсону. Если вы оставите более подробный ответ, я приму ваш, если только вы не почувствуете, что Джейсон заслуживает награды. - person Unknown; 22.04.2010
comment
К сожалению, документация по BrowserChannel довольно тонкая, и у меня нет непосредственного опыта работы с ней, поэтому я не могу точно сказать, как она решает эту конкретную проблему. Лучшее, что вы можете сделать, - это посмотреть на код и попытаться с ним разобраться. Если вы думаете, что я не заслуживаю награды, меня это устраивает, я просто пытался указать вам в полезном направлении. - person Jason Hall; 22.04.2010
comment
Есть вопрос на боковой панели, который, кажется, тоже может быть полезен? stackoverflow.com/questions/2481696/ - person Jason Hall; 22.04.2010
comment
@ Джейсон, я дам тебе награду, если ты останешься лучшим ответом. Но если ты сможешь улучшить его еще немного, я сразу дам тебе награду. - person Unknown; 22.04.2010

arrow_upward
0
arrow_downward

Я действительно понятия не имею, каков ответ. Но я знаю, что Opera поддерживает серверные события: http://my.opera.com/WebApplications/blog/show.dml/438711. Может это шаг навстречу анусеру? Я тоже не совсем уверен, но думаю, что они используют его в Opera Unite.

person Savageman    schedule 17.04.2010
comment
Нет, как я уже сказал, он не использует источник событий. Источник событий полностью сломан в Opera 10.51, и gmail все еще нормально передает gchat. - person Unknown; 18.04.2010

arrow_upward
0
arrow_downward

Я думаю, что скорее кроссбраузерный подход (включая Opera) может заключаться в потоковой передаче данных через приложение Adobe Flash. Хотя это приведет к зависимости от плагина Flash и не пользуется большой популярностью из-за этого.

person newtover    schedule 25.04.2010

arrow_upward
0
arrow_downward

Я являюсь автором текущего HTTP-сервера C ++, совместимого с goog.netBrowserChannel. Вы можете найти документы, которые я написал во время изучения протокола здесь:

http://code.google.com/p/libevent-browserchannel-server/wiki/BrowserChannelProtocol

Короче говоря, BrowserChannel использует вечные кадры в IE и потоковую передачу XHR во всех других браузерах. Протокол разделен на несколько этапов, первый из которых - тестирование сети:

1) проверьте сеть, чтобы убедиться, что ответ "потоковая передача" поддерживается (другими словами, прокси-сервер с буферизацией не существует);
2) проверьте доступ к различным префиксам сети (чтобы убедиться, что администратор сети не заблокировал доступ к чату)

После этого может начаться фактическая передача данных. Данные делятся на два канала (прямой и обратный). Обратный канал - это серия долгоживущих (около 4 минут каждый) запросов, используемых сервером для «потоковой передачи» контента клиенту. Для этого используется кодировка HTTP по частям. Клиент делает все возможное, чтобы один обратный канал всегда был открыт. Сервер будет закрывать его примерно каждые 4 минуты, после чего клиент откроет новый обратный канал. Прямой канал используется для отправки данных от клиента на сервер. Это перемещение данных выполняется по мере необходимости.

person ahochhaus    schedule 27.01.2012