да чего ты мне рассказываешь что я и так знаю, речь о том как передать window в window которые были созданы независимо друг от друга

Я немного не понял назначения WebSocket

Ты всё правильно понял. Они не нужны.

Очень хочется отказаться от AJAX, ибо он устанавливает кучу лишних соединений. Что посоветуете?

Посоветую отлюбиться от браузера и http-протокола, написав своё приложение с QT и удалённым сервером.

Согласен конечно. Только тогда возникают вопросы с авторизацией пользователей открывающихся сокет. Вот тут я правда теряюсь. Нужно как-то куки смотреть что ли.

Разин такой Разин

отлюбиться от браузера

Шаг назад, не? Я понимаю, что сейчас встраиваемые и карманные системы маломощны, но со временем они будут захвачены и порабощены всякими браузерами. Так что я смотрю в завтра.

и http-протокола

А вот он тут совсем ни при чём.

приложение с QT

Фу-фу-фу. Это же сколько всякого лишнего гумна в систему тащить.

Почитайте документацию по Faye / Socket.io . Там есть механизмы для аутентификации.

Шаг назад, не?

Да. Весь этот Websockets - это один большой шаг назад.

Я понимаю, что сейчас встраиваемые и карманные системы маломощны, но со временем они будут захвачены и порабощены всякими браузерами

«Мобильные приложения? Не не слышал.» Я вот, например на мобильных платформах больше наблюдаю увеличивающийся перекос от браузеров к другим реализациям клиентов всяких приложений.

А вот он тут совсем ни при чём.

Он тут в центре обсуждения, так как изначально задумывался таким: клиент инициирует соединение, отправляет запрос, получает ответ. А WebSockets - чисто костыль, которым пытаются подпереть то, чего не хватает в http.

Фу-фу-фу. Это же сколько всякого лишнего гумна в систему тащить.

Зато гибко, нативно и без тормозов.

А WebSockets - чисто костыль, которым пытаются подпереть то, чего не хватает в http.

Выглядит это так: брали паркетник для того, чтобы от работы до дому ездить, а потом решили, что надо бы ещё и на дачу песочка привезти пару-тройку тонн ... и приварили к крыше кузов, забыв про подвеску и двигатель. Запихали кое-как более мощный двигатель, оторвав крышку копота(не влазил) и поставили рессоры от трактора Беларусь. Посчитали - оказалось дешевле и качественнее было сразу грузовичок купить.

осчитали - оказалось дешевле и качественнее было сразу грузовичок купить.

Да и вышел какой-то уродец, над которым все ржуд.

sockjs socket.io тред не читал, в комете тоже нужно держать очередь чтоб не было лишних соединений, или это поллинг называется, сокет рулят но с честной поддержкой пока проблемы

Все элементарно: это обычный сокет, т.е. мы имеем реальную асинхронную связь. А XHR такого не умеет.

Я бы сказал, что XHR - это как раз асинхронный режим работы: послали запрос, работаем дальше, а ответ обрабатывается в колбэк-функции, указанной при отправке запроса. Но однонаправленный: сервер может только ответить на вызов, пусть и с продолжительной задержкой (благодаря чему и достигается псевдодвунаправленность, посылая запрос «дай статус, когда/если он изменится»). А вот сокет - это реально двунаправленный режим (поверх эзернета ещё и дуплексный).

Они не нужны.

Ретрограды-вебофобы не нужны.

приложение с QT

Покажи невырвиглазные приложения на Qt, желательно на чистом С или питоне. С т.з. дизайна любые десктопные тулкиты sosnooley перед HTML5/CSS3 и годятся лишь как запускалки вебкита/геко в недекорированном окне или на полный экран.

и удалённым сервером.

Какая разница, сервер какого протокола это будет? В ws по http идёт только хендшейк, между прочим.

Да, я не то сморозил.

Посоветую отлюбиться от браузера и http-протокола, написав своё приложение с QT и удалённым сервером.

Фу, как пóшло!

sockjs

Вебсокеты решат проблему связи не только вперед, но и назад, с сервера. А Ajax это делает путем ужасных костылей на подобии Comet.

Это все теория, а на практике, костыли на Comet - единственное что работает. Вебсокеты можешь взять на лопату, закрыть нос и выкинуть в ведро

на Qt, желательно на чистом С

фейл

Здесь фейл Qt, ибо кресты не нужны.

отказаться от AJAX, ибо он устанавливает кучу лишних соединений

слабо представляю, как можно избежать установки соединений, если необходимо взаимодействие с сервером. разве что keepalive, но это далеко не всегда приемлемое решение. тем более что там имеется свой таймаут.

гибко, нативно и без тормозов

сказочник

почему они не работают-то можно узнать?

Я понимаю, что сейчас встраиваемые и карманные системы маломощны, но со временем они будут захвачены и порабощены всякими браузерами. Так что я смотрю в завтра.

Для этого браузерам придется обзавестись большим количеством новых возможностей и сильно сменить основные концепции, став фактически ОС. Ты смотришь в какое-то другое, альтернативное завтра.

большим количеством новых возможностей

Это какими, например?

Все, что есть в Android, WP, iOS.

Внедряли WebSocket ещё с момента появления черновика 76. Написал сервачёк на Qt, работает уже больше года, всё отлично, все довольны.

В браузере писалось всё на голом JS, из библиотек — только JQuery.

Даже в седьмой венде поддерживается ws.

https://wiki.mozilla.org/WebAPI типа этих?

Flash, silverlight (мб java) могут эмитировать websocketы. Вопрос несколько некорректный, т.к. я не вижу где они конкурируют.

Ajax предназначается для, по-большей части, статичного контента, такого, который можно прокешировать, раздать через баллансировщик типа nginx, apache, который затем прокеширует браузер и сделает работу юзера более приятной (текст статей, пречень статей, карта сайта и т.д.) Ajax упрощает серверную архитектуру: не нужны сложные шаблоны, достаточно небольших фрагментов, или вообще json (клиент сам разберется что с ним делать).

Websocket предназначен для абсолютно динамического контента, который генерируется прямо сейчас и будет не нужен уже через 5 минут больше никогда (оповещения, координаты объектов). Websocket усложняет серверную архитектуру: он встанет рядом, он обязательно будет работать на калбэках.

Вобщем, это, практически, два параллельных мира, на мой взгляд.

сервачёк на Qt

Для меня одного это странно звучит?

Были заюзаны QtCore, QtNetwork, QtDBus и QtSql (скуль для других нужд) и сторонняя либа QJson.

А что не так?

Ну.. забавно, qt - гуи тулкит, а сервер - это нечто априори лишенное гуи, то, что будет работать там, где для гуи нет почти ничего.

qt - гуи тулкит

Вызывающе неверная информация. Qt - это framework. Я не использую GUI на сервере.

Да, Mozilla пытаются сделать примерно это в плане сервисных функций, но я больше про интерфейс.

Кстати, меня очень сильно удивляет упорство Mozilla, с которым они держатся за html, css и js.

а что интерфейс? и за что им следует держаться?

За NaCl.

Интерфейс — на веб-технологиях сейчас невозможно повторить поведение ни одной из ведущих мобильных платформ.

Нет, я тоже споткнулся об эту фразу ибо знаю «qt — это такой жирный тулкит». Оказалось, что это действительно универсальный фреймворк (но всё равно жирный).