Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Автор Alexander Gödde зачем-то показательно слеп и с первых строк проводит серию ложных утверждений, годных лишь для экскурсантов в музее, но не для ресурса со специалистами, знающих, что протокол — это не основание для ограничений на передачу чего-либо. Зачем? Так, что ли, проще объяснить появление нового протокола?
Итого, кому нужно было такое вступление? Если это — статья для студентов, то тут автор показал себя дремуче безграмотным. И как тогда доверять тем знаниям, которые он настрочил ниже?
Пусть, если автор такой, что счёл нужным не объяснять детям тонкости истории (очень самонадеянно, всё равно, что говорить, что камень не годился как орудие, а вот когда изобрели топор, весь мир перевернулся), то почему переводчик не счёл нужным это заметить? И сказать: вот тут автор много новой крутой новизны излагает, давайте простим ему этот лепет вначале? Зато потом он много хорошего про WAMP пишет таким же сладким складным языком, и я, мол, ручаюсь за него, что это уж точно правда.
AJAX-вызовы вывели работу web на новый уровень. Уже не нужно перезагружать страницу в ответ на каждый ввод информации пользователем.Где же упоминание про фреймы, при наличии которых тоже не нужно перезагружать страницу, а только фрейм, который может быть нулевых размеров и невидимым? Старые протоколы безопасности затем не мешали прочитать содержимое обновлённого фрейма из соседнего фрейма при монодоменных (важное ограничение) запросах.
А вот что AJAX не обеспечивает – так это обновления с сервера...Но правда в том, что обновление ПО как по eval(), так и несколькими другими способами, возможно как и по AJAX, так и через фреймы.
До появления AJAX интерактивные взаимодействия со страницей были тяжеловесными. Каждое из них требовало перезагрузки страницы, которая создавалась на сервере.Тяжеловесность заключалась лишь в лишнем нуль-фрейме, что отнимало не лишние ресурсы старых браузеров (например, в Netscape 4 рекомендовалось больше 100 фреймов не делать. Но обновляемая в нём страница могла быть просто скриптом. Более того, всегда работал способ подгрузки скриптов ( и стилей, и картинок) путём создания тега Script с src=URL_скрипта_с_любого_домена. Это позволяло подгружать и обновлять ПО без перезагрузки какой-либо страницы.Правда, совсем чисто и безошибочно браузеры это научились делать во времена примерно Firefox 1.0 или немногим ранее. А до него — следовало, всё же, обновлять страницу, например, с помощью document.write() (с обязательным document.close() в каком-то из браузеров).
У нас появилась возможность делать вызовы удалённых процедур (RPC).Это можно, как оговорено выше, было делать и до AJAX, и не одним способом (а тремя). Не в протоколе, конечно, RPC, но по сути RPC (Remote Procedure Call).
Итого, кому нужно было такое вступление? Если это — статья для студентов, то тут автор показал себя дремуче безграмотным. И как тогда доверять тем знаниям, которые он настрочил ниже?
Пусть, если автор такой, что счёл нужным не объяснять детям тонкости истории (очень самонадеянно, всё равно, что говорить, что камень не годился как орудие, а вот когда изобрели топор, весь мир перевернулся), то почему переводчик не счёл нужным это заметить? И сказать: вот тут автор много новой крутой новизны излагает, давайте простим ему этот лепет вначале? Зато потом он много хорошего про WAMP пишет таким же сладким складным языком, и я, мол, ручаюсь за него, что это уж точно правда.
О, да, прочитав чуть далее, я смутно начал догадываться, что и про Вебсокет он накосячит, не здесь, так дальше. Он столь же феерично и про Websocket пишет, не в этой статье, а по ссылке tavendo.com/blog/post/websocket-why-what-can-i-use-it/. Там он наглядно и красиво утверждает, что длительная передача от сервера к клиенту была невозможна (под рисунком), пока не придумали WebSocket. Не читайте его… Лучше, тут, к примеру, хотя бы грамотно вводят в курс про long polling: www.slideshare.net/ffdead/the-html5-websocket-api и ещё через Флеш работал заменитель вебсокетов, когда их не было. Кроме того, первый запрос на вебсокет, всё же, должен дать клиент. В презентации это всё прекрасно описано, в статье данного автора — нет («No more polling» в тексте и около).
Ну коли пошла такая пьянка, скажу про 3 моих реализации WAMP'а:
А еще есть слайды с моего выступления на MoscowJS: «Пара слов про WAMP».
Вдруг кому-то пригодится.
А еще есть слайды с моего выступления на MoscowJS: «Пара слов про WAMP».
Вдруг кому-то пригодится.
Кому будет интересна интеграция WAMP с PHP, обратите внимание на
Ratchet: WebSockets for PHP.
Oн использует REACT PHP для IOLoop`а и WAMP в качестве протокола.
Ratchet: WebSockets for PHP.
Oн использует REACT PHP для IOLoop`а и WAMP в качестве протокола.
Полноценная реализация WAMP роутера и клиента на PHP это voryx/Thruway
В Ratchet используется WAMP v1. Он уже считается устаревшим. Для v2, как верно заметил pronskiy надо юзать Thruway
Решаю похожую проблему в Booth. Это Node.js/CommonJS библиотека, поверх вебсокета предоставляет два интерфейса: PubSub (у меня это названо realtime) и request-response (названо requests). Реализация двусторонняя: как сервер, так и клиент могут выступать одновременно и в качестве источника и приёмника потоков данных, также обе стороны могут обращаться друг к дружке с запросами.
Запросы имеют promise API, а реалтайм — callback. Есть планы по реализации FRP для реалтайма на основе какой-нибудь существующей библиотеки, например, симпатичной мне либы Highland.
Запросы имеют promise API, а реалтайм — callback. Есть планы по реализации FRP для реалтайма на основе какой-нибудь существующей библиотеки, например, симпатичной мне либы Highland.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему одного AJAX недостаточно: протокол WAMP