Похоже, что Websockets в HTML 5 станет новым стандартом для push-сервера.
Означает ли это, что серверный push-взлом под названием Comet будет устаревшим?
Есть ли причина, по которой я должен научиться внедрять комету, когда скоро появятся Websockets (1-2 года) во всех основных браузерах?
Тогда я мог бы просто использовать Beaconpush или Pusher вместо этого правильно?
Означает ли это, что серверный push-взлом под названием Comet будет устаревшим?
WebSockets могут заменить Comet, AJAX, Long Polling и все хаки, чтобы обойти проблему, когда веб-браузеры не могли откройте простой сокет для двунаправленной связи с сервером.
Есть ли причина, по которой я должен научиться внедрять комету, когда WebSockets скоро будут доступны во всех основных браузерах?
Это зависит от того, что "скоро" означает для вас. Например, версия Internet Explorer (pre IE 9) не поддерживает API WebSockets.
ОБНОВЛЕНИЕ:
Это не было исчерпывающим ответом. Проверьте другие ответы и @jvenema в частности, для дальнейшего понимания этой темы.
Есть две части этой головоломки:
Q: Требуется ли клиентская часть "кометы"?
A: Да. Даже в ближайшие 2 года вы не увидите полную поддержку WebSockets в "основных" браузерах. IE8, к примеру, не поддерживает его, а также текущую версию FireFox. Учитывая, что IE6 был выпущен в 2001 году, и он все еще вокруг сегодня, я не вижу WebSockets как замену кометы полностью в ближайшее время.
Q: Требуется ли серверная часть "кометы"?
A: Да. Серверы комет предназначены для обработки долговременных HTTP-соединений, где нет "типичных" веб-серверов. Даже если клиентская сторона поддерживает WebSockets, серверная сторона все равно должна быть спроектирована для обработки нагрузки.
Кроме того, как упоминалось в "gustavogb", по крайней мере сейчас WebSockets не поддерживается должным образом во многих HTTP-прокси, поэтому пока все они не будут обновлены, нам все равно понадобится какой-то резервный механизм.
Короче говоря, комета, как она существует сегодня, не уходит в ближайшее время.
В качестве добавленного примечания: версии WebSockets, которые в настоящее время реализованы в Chrome и Safari, представляют собой два разных проекта, а работа над "текущим" проектом все еще находится в очень тяжелом развитии, поэтому я даже не считаю, что это реалистично сказать, что поддержка WebSockets на данный момент является работоспособной. Как любопытство или для обучения, конечно, но не как настоящая спецификация, по крайней мере, еще нет.
[Обновить, 2/23/11]
Текущая версия Safari имеет сломанную реализацию (она не отправляет правильный заголовок), Firefox 4 просто устарел на WebSockets, поэтому он не будет включен, и IE9 не выглядит хорошим ни. Похоже, что Chrome - единственная рабочая версия с включенной версией черновика, поэтому WebSockets еще предстоит пройти долгий путь.
В среднесрочной перспективе websockets не заменит кометные решения не только из-за отсутствия поддержки браузеров, но и из-за HTTP Proxies. До тех пор, пока большинство HTTP-прокси не будут обновлены для поддержки соединений с веб-соединениями, веб-разработчикам придется внедрять альтернативные решения на основе кометных методов для работы в сетях, "защищенных" такими прокси-серверами.
В коротких/средних веб-папках будет использоваться только оптимизация, которая будет использоваться, когда она будет доступна, но вам все равно придется использовать длинный опрос (комету), чтобы полагаться на то, когда веб-сайты недоступны, если вам нужно сделать свой сайт доступным для множество клиентов с сетями/браузерами, которые не под вашим контролем.
Надеюсь, это будет абстрагировано фреймворками javascript и будет прозрачным для веб-разработчиков.
Рассмотрим использование библиотеки/рамки веб-сокета, которая возвращается в комету при отсутствии поддержки браузера.
Выйти из Orbited и Hookbox.
Да, потому что "скоро" - очень скользкий термин. Многим интернет-магазинам по-прежнему приходится поддерживать IE6.
Нет, потому что в последнее время появилось сыпь кометных фреймворков и серверов, которые скоро сделают это в значительной степени ненужным для вас, чтобы ваши руки были грязными в подвале.
Да, потому что " скоро" - очень скользкий термин...
Устав рабочей группы [] рабочей группы, заданной с помощью websockets, BiDirectional или Server-Initiated HTTP (hybi):
Описание рабочей группы
HTTP чаще всего используется в качестве протокола запроса/ответа, ведущего для опроса клиентов для новых данных или пользователей, нажавших кнопку обновления в их браузеры. Последние веб-приложения ищут способы общения с веб-серверами в реальном времени, нажатие данных с серверной стороны на клиент, как только он будет доступен. Однако эти приложения в существующий может использовать только различные механизмы HTTP (например, длительный опрос запросы) для двунаправленного взаимодействия с веб-серверами.
Рабочая группа Hypertext-Twoirectional (HyBi) будет искать стандартизация одного подхода для поддержания двунаправленного связь между HTTP-клиентом, сервером и промежуточным которые будут обеспечивать большую эффективность по сравнению с текущими использование запросов на висячие.
HTTP по-прежнему играет определенную роль; это гибкая система, ориентированная на сообщения. были разработаны websockets, чтобы обеспечить двунаправленность и избежать проблемы с длинным опросом. [он делает это хорошо]. но это проще, чем http. и есть много вещей, которые полезны в отношении http. непременно будет продолжаться прогресс, обогащающий http двунаправленную связь, будь то комета или другие технологии push. моя собственная скромная попытка [http://github.com/rektide/pipe-layer].