Comments 29
Не только вебкит-браузеры работают с вебсокетами. Опера их поддерживает, просто по умолчанию они выключены, включаются тут
opera:config#UserPrefs|EnableWebSockets
Firefox тоже поддерживает, и тоже отключено по умолчанию, хотя вроде как говорили что в шестой версии они будут включены по умолчанию, тут пользователи фаерфокса подскажут точнее.
opera:config#UserPrefs|EnableWebSockets
Firefox тоже поддерживает, и тоже отключено по умолчанию, хотя вроде как говорили что в шестой версии они будут включены по умолчанию, тут пользователи фаерфокса подскажут точнее.
да да, в курсе, что FF и Opera отключили WS по-умолчанию, но пользователям не объяснишь…
В моем случае, автоматизацией пользоваться будут американцы, подавляющим большинством они пользуются браузером Safari.
На сегодняшний момент вижу большой потенциал использования вебсокетов в Google Apps
В моем случае, автоматизацией пользоваться будут американцы, подавляющим большинством они пользуются браузером Safari.
На сегодняшний момент вижу большой потенциал использования вебсокетов в Google Apps
>В моем случае, автоматизацией пользоваться будут американцы, подавляющим большинством они пользуются браузером Safari.
статистика с вами не согласна
gs.statcounter.com/#browser-US-monthly-201008-201108
если вы только не про ограниченный круг американских заказчиков :)
статистика с вами не согласна
gs.statcounter.com/#browser-US-monthly-201008-201108
если вы только не про ограниченный круг американских заказчиков :)
Извиняюсь за двусмысленное понятие предолжения… Заказчик в США, он, а также люди в его агентстве используют маки
UFO just landed and posted this here
Совсем не обязательно, конечно! Вы работали за маком в Safari? — Мне кажется, очень приятный минималистичный браузер. Все прокрутки работают плавно, анимация не тормозит. Safari на маке очень не похож на Safari для Windows, для серфинга очень даже ничего.
Я сколнен предположить, что большинству пользователей мака не нужны другие браузеры, одного Safari достаточно.
Я сколнен предположить, что большинству пользователей мака не нужны другие браузеры, одного Safari достаточно.
>да да, в курсе, что FF и Opera отключили WS по-умолчанию, но пользователям не объяснишь…
не только пользователям, www.webmonkey.com/2010/12/security-flaws-force-firefox-opera-to-turn-off-websockets/
не только пользователям, www.webmonkey.com/2010/12/security-flaws-force-firefox-opera-to-turn-off-websockets/
Firefox and Opera have both disabled support for HTML5 WebSockets in the latest builds of their respective browsers. The move comes on the heels of a protocol vulnerability that could leave thousands of sites harboring malicious code.
Зачем Jetty использовать, если вы все равно Glassfish используете?
В нем же есть все необходимое для работы с WebSocket…
В нем же есть все необходимое для работы с WebSocket…
Я очень хочу написать пост про JWebSocket… Как закончу серию этих постов, обязательно, напишу про JWebSocket! Какой смысл использовать JWebSocket, который основан на Jetty WebSocket, который в свою очередь основан на Netty? Не легче использовать сразу Netty, программируя базовые уровни обмена данными через UDP?
Вы извините. Может переборщил. Пьяный сегодня. День Программиста. Что я хотел сказать — каждый более высокий уровень программирования почти всегда сложнее чем более низкий.
Это вы уже серьезно заговорились:
>> программируя базовые уровни обмена данными через UDP…
Netty вы используете косвенно, поэтому по вашей логике не понятно зачем Jetty WebSockets?
Ответ простой… Данные обертки существуют не просто так, а чтобы упростить реализацию, которая в вашем случае, необоснована избыточна за счет спуска на другой уровень абстракции. А если посмотреть исходники оберток, то можно и обнаружить невероятные заплатки в некоторых местах, которые уберегают от лишних проблем.
>> программируя базовые уровни обмена данными через UDP…
Netty вы используете косвенно, поэтому по вашей логике не понятно зачем Jetty WebSockets?
Ответ простой… Данные обертки существуют не просто так, а чтобы упростить реализацию, которая в вашем случае, необоснована избыточна за счет спуска на другой уровень абстракции. А если посмотреть исходники оберток, то можно и обнаружить невероятные заплатки в некоторых местах, которые уберегают от лишних проблем.
> браузер отправляет запрос каждую секунду создавая лишнюю нагрузку на:
Просто чтобы Вы знали (вдруг куда-нибудь программистом устраиваться пойдёте, мало ли) — есть такая волшебная штука как long polling. Которая а) практически никого не нагружает и б) совместима чуть ли не с IE6.
Будьте здоровы и не пейте много.
Просто чтобы Вы знали (вдруг куда-нибудь программистом устраиваться пойдёте, мало ли) — есть такая волшебная штука как long polling. Которая а) практически никого не нагружает и б) совместима чуть ли не с IE6.
Будьте здоровы и не пейте много.
Сколько бы я не выпил уже…
long polling для меня — это «бесконечный iframe» версии 2.0
Может быть, это мое субъективное мнение… Но зачем использовать XMLHttpRequest для отложенного ответа в IE6, если бесконечный iframe поддерживается даже в IE3 на Windows 95.
Кстати, Windows 95 даже IPv4 без бубна не тянет)))
long polling для меня — это «бесконечный iframe» версии 2.0
Может быть, это мое субъективное мнение… Но зачем использовать XMLHttpRequest для отложенного ответа в IE6, если бесконечный iframe поддерживается даже в IE3 на Windows 95.
Кстати, Windows 95 даже IPv4 без бубна не тянет)))
А чем плох «бесконечный iframe» и long-polling? И тем более, чтобы веб разработчики поняли?:)
Нам у себя в проекте тоже понадобилось использовать возможности push-нотификаций с сервера. И тоже на java. Использование только web socket'ов — пока рановато. В итоге пришли к использованию Atmosphere. Поддерживает все концепции: бесконечный iframe, long-polling, web-socket, при этом старается «по умному» определить нужную. И, кроме того, абстрагирует код от конкретного сервера приложений. Перенести проект на новый сервер приложений можно просто заменив библиотеку в зависимостях.
Нам у себя в проекте тоже понадобилось использовать возможности push-нотификаций с сервера. И тоже на java. Использование только web socket'ов — пока рановато. В итоге пришли к использованию Atmosphere. Поддерживает все концепции: бесконечный iframe, long-polling, web-socket, при этом старается «по умному» определить нужную. И, кроме того, абстрагирует код от конкретного сервера приложений. Перенести проект на новый сервер приложений можно просто заменив библиотеку в зависимостях.
Согласен. Все зависит от задачи. WebSocket нельзя использовать как единственный способ связи на сайтах. Но если речь идет об автоматизации деятельности предприятия, где разработчик диктует системные требования?
Более того, WebSocket прекрасно поддерживает Chrome. В виду последних событий, развитие Google Apps в сомнения не вводит!
Также технология очень популярна в развитии web-приложений для Android и iOS. iOS и Android используют миллионы, многие ресурсы www делают отдельный клиент для этих платформ, так как, скорее всего такие пользователи — именно наши целевые клиенты, — клиенты, которые готовы платить $5/мес. за достойный сервис.
А рано или поздно все равно iframe и long-polling уйдет в прошлое. Главное тут то, чтобы во-время просветить себя в новых технологиях, тем более, что они предоставляют гораздо более лаконичный и простой доступ к данным без каких либо костылей. Не согласны?
Более того, WebSocket прекрасно поддерживает Chrome. В виду последних событий, развитие Google Apps в сомнения не вводит!
Также технология очень популярна в развитии web-приложений для Android и iOS. iOS и Android используют миллионы, многие ресурсы www делают отдельный клиент для этих платформ, так как, скорее всего такие пользователи — именно наши целевые клиенты, — клиенты, которые готовы платить $5/мес. за достойный сервис.
А рано или поздно все равно iframe и long-polling уйдет в прошлое. Главное тут то, чтобы во-время просветить себя в новых технологиях, тем более, что они предоставляют гораздо более лаконичный и простой доступ к данным без каких либо костылей. Не согласны?
Хмм, я конечно сварщик не настоящий в Jetty, но чем вам jetty continuation не угодил? www.ibm.com/developerworks/ru/library/j-jettydwr/
Про Jetty можно написать десятки постов. Он достоин отдельного блога. Вот так вышло, что написал про WebSocket, а не про continuation
Вы в посте утверждаете что для решения поставленной задачи есть три варианта. Почему вы не рассматривали вариант jetty continuation? Почему данный вариант вам не подошел?
jetty continuation использует XMLHttpRequest, посему он не четвертый вариант, а второй)
Информации по XMLHttpRequest существует достаточно много. Я же хотел рассказать про WebSocket. А в моем проекте, который я уже сдал, я не использовал Jetty напрямую. Я реализовал WebSocket с использованием JWebSocket, у которого есть поддержка соединения через FlashBridge. Про JWebSocket хочу написать отдельную серию постов.
Информации по XMLHttpRequest существует достаточно много. Я же хотел рассказать про WebSocket. А в моем проекте, который я уже сдал, я не использовал Jetty напрямую. Я реализовал WebSocket с использованием JWebSocket, у которого есть поддержка соединения через FlashBridge. Про JWebSocket хочу написать отдельную серию постов.
Хорошо, но если jetty continuation второй вариант, то как быть с недостатком — «браузер отправляет запрос каждую секунду»? Это ведь неправильно в данном случае, соединение устанавливается и клиент ждет пока сервер найдет для него данные.
Да и второй недостаток под вопросом — «тяжело отследить онлайн-статус пользователя». Вы же храните в памяти набор открытых сокетов, точно также можно continuation хранить активные.
Конечно у jetty continuation есть недостатки (низкий уровень абстракции, открытие нового соединения для следующего запроса). Но в принципе они преодолимы и не так страшны, да и работают практически везде где есть xmlhttprequest. К тому же не стоит забывать что jetty continuation используются как библиотека для построения websocket.
Да и второй недостаток под вопросом — «тяжело отследить онлайн-статус пользователя». Вы же храните в памяти набор открытых сокетов, точно также можно continuation хранить активные.
Конечно у jetty continuation есть недостатки (низкий уровень абстракции, открытие нового соединения для следующего запроса). Но в принципе они преодолимы и не так страшны, да и работают практически везде где есть xmlhttprequest. К тому же не стоит забывать что jetty continuation используются как библиотека для построения websocket.
Ну это уже немножко другое, но можно использовать для аналогичных задач.
В этом случае нужно вспомнить очень не плохой engine на базе Jetty: Cometd
В этом случае нужно вспомнить очень не плохой engine на базе Jetty: Cometd
Запускать Jetty внутри уже существующего контейнера — то еще извращение!
Быстрый поиск вывел на эту статью java.dzone.com/articles/tomcat-websockets-html5
Вообще, я думаю, стоит подождать, пока контейнеры не начнут поддерживать JSR-340 по-умолчанию, а пока использовать проверенные способы типа long pooling.
Быстрый поиск вывел на эту статью java.dzone.com/articles/tomcat-websockets-html5
Вообще, я думаю, стоит подождать, пока контейнеры не начнут поддерживать JSR-340 по-умолчанию, а пока использовать проверенные способы типа long pooling.
Sign up to leave a comment.
WebSocket: Реализация web-приложения с использованием Jetty Web Socket. Часть 1