Как стать автором
Обновить

Комментарии 29

Не только вебкит-браузеры работают с вебсокетами. Опера их поддерживает, просто по умолчанию они выключены, включаются тут
opera:config#UserPrefs|EnableWebSockets
Firefox тоже поддерживает, и тоже отключено по умолчанию, хотя вроде как говорили что в шестой версии они будут включены по умолчанию, тут пользователи фаерфокса подскажут точнее.
да да, в курсе, что FF и Opera отключили WS по-умолчанию, но пользователям не объяснишь…

В моем случае, автоматизацией пользоваться будут американцы, подавляющим большинством они пользуются браузером Safari.

На сегодняшний момент вижу большой потенциал использования вебсокетов в Google Apps
>В моем случае, автоматизацией пользоваться будут американцы, подавляющим большинством они пользуются браузером Safari.

статистика с вами не согласна
gs.statcounter.com/#browser-US-monthly-201008-201108

если вы только не про ограниченный круг американских заказчиков :)
Извиняюсь за двусмысленное понятие предолжения… Заказчик в США, он, а также люди в его агентстве используют маки
НЛО прилетело и опубликовало эту надпись здесь
Совсем не обязательно, конечно! Вы работали за маком в Safari? — Мне кажется, очень приятный минималистичный браузер. Все прокрутки работают плавно, анимация не тормозит. Safari на маке очень не похож на Safari для Windows, для серфинга очень даже ничего.

Я сколнен предположить, что большинству пользователей мака не нужны другие браузеры, одного Safari достаточно.
НЛО прилетело и опубликовало эту надпись здесь
Ну Сафари для маков — единственный браузер, который работает также как и весь Мак.
Все остальные браузеры работают на маке как-то «по-виндозовски».
Мне кажется, пользователи мака отказываются от Safari только из-за ненависти к IE
(это не относится к web-разработчикам, которым нужен firebug и пр.)
>да да, в курсе, что FF и Opera отключили WS по-умолчанию, но пользователям не объяснишь…

не только пользователям, 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…
Я очень хочу написать пост про JWebSocket… Как закончу серию этих постов, обязательно, напишу про JWebSocket! Какой смысл использовать JWebSocket, который основан на Jetty WebSocket, который в свою очередь основан на Netty? Не легче использовать сразу Netty, программируя базовые уровни обмена данными через UDP?
Вы извините. Может переборщил. Пьяный сегодня. День Программиста. Что я хотел сказать — каждый более высокий уровень программирования почти всегда сложнее чем более низкий.
Я сам комментарий не туда запостил… С празником!
Это вы уже серьезно заговорились:
>> программируя базовые уровни обмена данными через UDP…

Netty вы используете косвенно, поэтому по вашей логике не понятно зачем Jetty WebSockets?

Ответ простой… Данные обертки существуют не просто так, а чтобы упростить реализацию, которая в вашем случае, необоснована избыточна за счет спуска на другой уровень абстракции. А если посмотреть исходники оберток, то можно и обнаружить невероятные заплатки в некоторых местах, которые уберегают от лишних проблем.
Не готов к холивару… Писал об этом выше. Извини. Давайте продолжим, когда будем трезвыми) Сегодня Ваш день! Я надеюсь, вы достойно прокомментируете вторую часть статьи. Спасибо за ваш комментарий. Вы не представляете, как я Вам рад сегодня!
> браузер отправляет запрос каждую секунду создавая лишнюю нагрузку на:

Просто чтобы Вы знали (вдруг куда-нибудь программистом устраиваться пойдёте, мало ли) — есть такая волшебная штука как long polling. Которая а) практически никого не нагружает и б) совместима чуть ли не с IE6.

Будьте здоровы и не пейте много.
Сколько бы я не выпил уже…

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, при этом старается «по умному» определить нужную. И, кроме того, абстрагирует код от конкретного сервера приложений. Перенести проект на новый сервер приложений можно просто заменив библиотеку в зависимостях.
Согласен. Все зависит от задачи. WebSocket нельзя использовать как единственный способ связи на сайтах. Но если речь идет об автоматизации деятельности предприятия, где разработчик диктует системные требования?

Более того, WebSocket прекрасно поддерживает Chrome. В виду последних событий, развитие Google Apps в сомнения не вводит!

Также технология очень популярна в развитии web-приложений для Android и iOS. iOS и Android используют миллионы, многие ресурсы www делают отдельный клиент для этих платформ, так как, скорее всего такие пользователи — именно наши целевые клиенты, — клиенты, которые готовы платить $5/мес. за достойный сервис.

А рано или поздно все равно iframe и long-polling уйдет в прошлое. Главное тут то, чтобы во-время просветить себя в новых технологиях, тем более, что они предоставляют гораздо более лаконичный и простой доступ к данным без каких либо костылей. Не согласны?
Про Jetty можно написать десятки постов. Он достоин отдельного блога. Вот так вышло, что написал про WebSocket, а не про continuation
Вы в посте утверждаете что для решения поставленной задачи есть три варианта. Почему вы не рассматривали вариант jetty continuation? Почему данный вариант вам не подошел?
jetty continuation использует XMLHttpRequest, посему он не четвертый вариант, а второй)
Информации по XMLHttpRequest существует достаточно много. Я же хотел рассказать про WebSocket. А в моем проекте, который я уже сдал, я не использовал Jetty напрямую. Я реализовал WebSocket с использованием JWebSocket, у которого есть поддержка соединения через FlashBridge. Про JWebSocket хочу написать отдельную серию постов.
Хорошо, но если jetty continuation второй вариант, то как быть с недостатком — «браузер отправляет запрос каждую секунду»? Это ведь неправильно в данном случае, соединение устанавливается и клиент ждет пока сервер найдет для него данные.

Да и второй недостаток под вопросом — «тяжело отследить онлайн-статус пользователя». Вы же храните в памяти набор открытых сокетов, точно также можно continuation хранить активные.

Конечно у jetty continuation есть недостатки (низкий уровень абстракции, открытие нового соединения для следующего запроса). Но в принципе они преодолимы и не так страшны, да и работают практически везде где есть xmlhttprequest. К тому же не стоит забывать что jetty continuation используются как библиотека для построения websocket.
Спасибо за замечания. Но я ставил цель показать самый простой способ использования WebSocket в своих проектах. Тем более это наиболее удобный вариант для реализации web-клиентов для iPhone и Android-смартфонов, а также Google Apps. — что без сомнения делает это решение востребованным в наши дни.
Ну это уже немножко другое, но можно использовать для аналогичных задач.
В этом случае нужно вспомнить очень не плохой engine на базе Jetty: Cometd
Запускать Jetty внутри уже существующего контейнера — то еще извращение!
Быстрый поиск вывел на эту статью java.dzone.com/articles/tomcat-websockets-html5
Вообще, я думаю, стоит подождать, пока контейнеры не начнут поддерживать JSR-340 по-умолчанию, а пока использовать проверенные способы типа long pooling.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории