Комментарии 12
Какие приложения реализованы на Cramp?
Интересная технология, спасибо за статью!
Насколько адекватно сейчас поддерживать одни только вебсокеты? Мне кажется, подход Socket.io или Faye c fallback на другие протоколы более актуальный в данное время. Т.е. в перспективе, когда все баузеры будут уметь вебсокеты единообразно, работа с нативными библотеками будет более прозрачная, но сейчас иметь адаптер, вроде вышеупомянутых библиотек, мне кажется горадзо менее рискованным.
Насколько адекватно сейчас поддерживать одни только вебсокеты? Мне кажется, подход Socket.io или Faye c fallback на другие протоколы более актуальный в данное время. Т.е. в перспективе, когда все баузеры будут уметь вебсокеты единообразно, работа с нативными библотеками будет более прозрачная, но сейчас иметь адаптер, вроде вышеупомянутых библиотек, мне кажется горадзо менее рискованным.
socket.io не всегда подходит, это уже жевали неоднократно. если вам нужна настоящая асинхронность со всеми вытекающими, лучше использовать WebSocket или flash-прокладку, если нет — зачем вообще парится? в первом случае все равно не взлетит, во втором побарахтаетесь и откажитесь. если, конечно, это будет что-то круче сферических хеловордов.
Не совсем понял вашу точку зрения. Что значит «настоящая асинхронность со всеми вытекающими», особенно для клиента на js? Какие проблемы возникли у вас при использовании Socket.io?
socket.io как раз использует WebSocket или flash-прокладку, или еще несколько транспорта, в зависимости от возможностей браузера.
Даже если не поддерживать старые браузеры, классно использовать апи, а не разбираться с разными транспортами. Тем более socket.io активно развивается, а значит, либу улучшают и если появится новый перспективный транспорт, возможно не придется ничего переписывать.
Даже если не поддерживать старые браузеры, классно использовать апи, а не разбираться с разными транспортами. Тем более socket.io активно развивается, а значит, либу улучшают и если появится новый перспективный транспорт, возможно не придется ничего переписывать.
все остальные транспорты уже не websocket, а прокладка просто его эмулирует. поллинг 4 раза в секунду, например, для вас нормально? socket.io не для такого
раз в 12 секунд вроде поллинг…
Я тоже не понял, чем socket.io не подходит.
Тем, что безсмысленны его попытки эмулировать websocket, если таковой не поддерживается?
Мне лично приятнее ещё и использовать в работе api от socket.io, в котором есть разные возможности типа custom events, сессионность, несколько сервисов на одном порту, обратные вызовы и прочее.
Тем, что безсмысленны его попытки эмулировать websocket, если таковой не поддерживается?
Мне лично приятнее ещё и использовать в работе api от socket.io, в котором есть разные возможности типа custom events, сессионность, несколько сервисов на одном порту, обратные вызовы и прочее.
кстати говоря в Cramp можно еще использовать long-polling, в статье об этом не сказано, просто не считаю это очень актуальной фичей на данный момент
а подложку на флэше нужно делать на клиенте, Cramp на данный момент никакой клиентской части не предоставляет, в документации например советуют использовать github.com/gimite/web-socket-js
а подложку на флэше нужно делать на клиенте, Cramp на данный момент никакой клиентской части не предоставляет, в документации например советуют использовать github.com/gimite/web-socket-js
Я верно понимаю, что если это сделано на EM, то нужно быть очень осторожным с блокирующими ф-циями, вроде долгих запросов к БД — это заблокирует сервер в целом? то есть нужно использовать что то вроде em-mysql?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Асинхронный ruby-фреймворк Cramp: архитектура и использование