AJAX выдвигает аберрацию протокола HTTP?

Question

Разработка элегантной архитектуры Pub-Sub в веб-ориентированных приложениях - это настоящее испытание. Хотя есть некоторые очень интересные решения, использующие длинные опрашивающие соединения (например, COMET) и повторяющиеся тайм-ауты (например, js setTimeout). IMHO AJAX push все еще выглядит как слой твиков и хаков, заставляющих невинный протокол HTTP.

Так что же вы думаете AJAX подталкивает аберрацию протокола HTTP?

Какие еще альтернативы вы могли бы рассмотреть в веб-архитектуре?

Answer 1

Другой вариант, который я видел ранее, - это использование небольшого скрытого Java или Flash для подключения через удаленные серверы через обычные сокеты. Затем сервер может передавать данные / события через эти сокеты в любое время без какого-либо опроса клиента.

Flash немного лучше IMO, так как не требует подписанного апплета (который выскакивает предупреждения безопасности для пользователя). Сокеты были в той или иной форме в течение 9 лет, хотя до Flash 9 / AS3 у вас не было «чистых» сокетов, которые можно было использовать для подключения к любому типу службы (ранее требовалось, чтобы сообщения заканчивается нулевым пакетом, что означает, что вы должны были разработать свой протокол специально для флэш-памяти, а не использовать XMPP или SMTP или любой существующий протокол)

Answer 2

Какие другие альтернативы вы могли бы считаете в веб архитектуре?

HTML 5 API веб-сокетов и Отправленные на сервер события выглядят многообещающе на будущее. IE пока не поддерживает веб-сокеты, а отправленные сервером события все еще являются экспериментальными. Предложение Дугласа Крокфорда JSONRequest также может быть интересной альтернативой AJAX push, но оно еще не реализовано в современных браузерах.

Пока что я буду придерживаться Кометы .

Answer 3

Опрос - это способ веб-архитектуры в pub-sub. Это работает хорошо, когда клиенты опрашивают нечасто, и ответы могут кэшироваться и делиться (например, RSS-лента блога). Держать tcp-сокет открытым для каждого клиента, как и в случае с кометой, не идеальный способ использования http. Однако если ваше приложение работает в веб-браузере и требует частых уникальных обновлений для каждого клиента, это неплохой способ сделать это.

Комета и опрос ресурсов для каждого клиента не являются полностью оскорбительными для http или Интернета - просто HTTP и Интернет были разработаны специально для совместного использования одних и тех же ресурсов (например, веб-страниц) среди многих клиентов, поэтому это работает лучше всего.

Answer 4

Просто подумайте о наиболее распространенных реализациях Comet, просто о том, что вам нужно обмануть браузер, заставив его думать, что он получает многочастный ответ или бесконечно длинный html внутри iframe, достаточно, чтобы поднять флаг о том, подходит ли это технологии или нет для работы.