Здравствуйте, mkizub, Вы писали:
M>Я совсем недавно писал про то, что сейчас началось время, когда на ура пройдёт смена технологий веб-программирования. M>Вот здесь
И это только начало.
Ерго, кто первым встанет с заменой HTML/CSS/PHP на что-то более приемлимое для web-2.0 — того и тапки.
Это я в том смысле, что веб-программирование сейчас самый что ни на есть мэйнстрим, и им здесь больше народу занимается, чем компиляторами и хаскелями вместе взятыми. Им и рекомендую поторопиться.
Когда-то поклонники дельфи проделали колоссальную работу по переписыванию/переводу Platform SDK и MSDN на свой язык, по написанию компонентов на каждый сервис ОС. А потом все было выброшено.
Так думаю и с веб будет — сначала они переизобретут все-все-все, а потом это будет выброшено, потому что никому этих огородов не надо.
Когда-нибудь они изобретут сервисы — веб-приложения, которые могут работать резидентно, а не во время нахождения на сайте. В этот день веб и умрет
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mkizub, Вы писали:
M>>Я совсем недавно писал про то, что сейчас началось время, когда на ура пройдёт смена технологий веб-программирования. M>>Вот здесь
писал.
M>>Так первая ласточка прилетела. M>>Web Sockets Now Available In Google Chrome
M>>И это только начало.
VD>А нет ощущения, что Яваскрипт — это не тот путь? Может на Силверлайт и Флэш со строготипизированными языками обратить внимание?
Я так понимаю, что WebSockets имеет такое-же отношение к JavaScript, как CGI к perl
Здравствуйте, mkizub, Вы писали:
m> M>>Было: заголовок (метаданные) + данные, послали, получили ответ, всё. m> M>>Стало: открыли соединение, гоняем туда-сюда данные в формате к HTTP отношения не имеющем. m> M>>Что общего осталось? А "остальное", что называется, "не пригодилось".
m> M>Вообще-то в HTTP есть до хрена всего полезного, http://webmachine.basho.com/diagram.html и, чувствую, для вебсокетов это все будут заново переизобретать.
m> Не будут. Соединение уже установлено, никакие access denied или service moved уже не нужны. Ты по сокету гоняешь данные своей аппликухой. Не нужно ради очередных нескольких байт продираться через всю эту диаграмму.
А как же, например, load balancing? 307 Temporary redirect для этого очень даже ничего.
Вряд ли.
M>Было: заголовок (метаданные) + данные, послали, получили ответ, всё. M>Стало: открыли соединение, гоняем туда-сюда данные в формате к HTTP отношения не имеющем.
И снова переизобретаем все-то, что было в HTTP. Всякие там редиректы, ошибочные ситуации. К тому же, в твоем случае, оно все не стандартизовано, либо заново стандартизуем, либо у нас хаос.
M>Что общего осталось? А "остальное", что называется, "не пригодилось".
Скорее, все осталось и пригодилось. Просто добавилась новая возможность, например, отображать на страничке какие-либо данные в "реальном" времени.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, mkizub, Вы писали:
M>Я совсем недавно писал про то, что сейчас началось время, когда на ура пройдёт смена технологий веб-программирования. M>Вот здесь
Здравствуйте, VladD2, Вы писали:
VD>А нет ощущения, что Яваскрипт — это не тот путь? Может на Силверлайт и Флэш со строготипизированными языками обратить внимание?
Во флеше тот же самый ECMAScript, или появилось нечто новое?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, VladD2, Вы писали:
VD>>А нет ощущения, что Яваскрипт — это не тот путь? Может на Силверлайт и Флэш со строготипизированными языками обратить внимание?
К>Во флеше тот же самый ECMAScript, или появилось нечто новое?
ActionScript, в котором присутствует строгая типизация.
Здравствуйте, Курилка, Вы писали:
К>Во флеше тот же самый ECMAScript, или появилось нечто новое?
С некоторых пор там типизированный Яваскрипт. Как я понял, пока что типизация не обязательная и она мало что дает с точки зрения производительности, но все же проблему больших проектов это уже решает. Силверлайт типизированный изначально.
И там, и там наличие асинхронного протокола не проблема.
В общем, на мой взгляд, развитие UI в Web-е должно идти по пути развития этих технологий. В обоих много проблем, но вектор развития верный. А вот создание примочек для оживления яваскрита — это тупиковый путь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Я так понимаю, что WebSockets имеет такое-же отношение к JavaScript, как CGI к perl M>Лично я здесь ничего javascript-ового не вижу. M>Я так полагаю, в броузере можно будет и java и .net использовать, а на сервере вообще что угодно.
У жаббы и нета есть вполне нормальные сокеты. Им этот костыль нафиг не нужен.
Здравствуйте, CreatorCray, Вы писали:
M>>Я так понимаю, что WebSockets имеет такое-же отношение к JavaScript, как CGI к perl M>>Лично я здесь ничего javascript-ового не вижу. M>>Я так полагаю, в броузере можно будет и java и .net использовать, а на сервере вообще что угодно. CC>У жаббы и нета есть вполне нормальные сокеты. Им этот костыль нафиг не нужен.
Так и в javascript можно добавить сокеты, без изобретения нового протокола.
Суть WebSockets, как я понял, в том, что HTTP посылается лесом, вместо него вводится новый, простой,
лёгкий, протокол, a-la sockets, но уже с готовым мультиплексированием и без дополнительных наворотов
полноценных BSD sockets, которые веб-аппликухе нафиг не нужны.
В контексте того моего поста, со ссылки на который я начал ветку.
WebSockets — это просто один из шагов по выкидыванию лишнего и ненужного. Точно так-же надо выкинут/упростить
HTML/JavaScript/etc. Просто раньше такие попытки были бесполезны и изначально обречены, а теперь они
имеют шанс. Кстати, я очень надеюсь, что в эту волну перемен сумеет вписаться и IPv6 или что-то подобное.
А то все эти роутеры и nat-ы просто задолбали.
Ну, вот как в экономике — всё было более-менее стабильно, а потом бах — Кризис. До него, скажем, Россия
или Китай могли сколько угодно пыжится, и пытаться заменить доллар рублём или юанем — и ничего бы не
вышло. Просто потому, что система (доллара) была достаточно устойчива и удовлетворяла большинство
"пользователей". А теперь — можно. Получится или нет — это вопрос открытый. Но сама принципиальная
возможность — есть.
Здравствуйте, mkizub, Вы писали:
CC>>У жаббы и нета есть вполне нормальные сокеты. Им этот костыль нафиг не нужен.
M>Так и в javascript можно добавить сокеты, без изобретения нового протокола. M>Суть WebSockets, как я понял, в том, что HTTP посылается лесом, вместо него вводится новый, простой, M>лёгкий, протокол, a-la sockets, но уже с готовым мультиплексированием и без дополнительных наворотов M>полноценных BSD sockets, которые веб-аппликухе нафиг не нужны.
Да не, насколько я понимаю (а в веб-технологиях я профан и могу ошибаться) HTTP никуда не посылается, а расширяется. Т.к. HTTP изначально задумывался как расширяемый протокол. Расширяется добавляя возможность асинхронно клиенту и серверу обмениваться данными. Это типа, лесом идут всякие Comet'ы, а не HTTP.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Да не, насколько я понимаю (а в веб-технологиях я профан и могу ошибаться) HTTP никуда не посылается, а расширяется. Т.к. HTTP изначально задумывался как расширяемый протокол. Расширяется добавляя возможность асинхронно клиенту и серверу обмениваться данными. Это типа, лесом идут всякие Comet'ы, а не HTTP.
Насколько я понял, будет используется команда HTTP CONNECT для установки соединения, которая давно используется для туннелей.
Кстати, эта команда может быть запрещена настройками proxy.
Здравствуйте, yumi, Вы писали:
Y>Да не, насколько я понимаю (а в веб-технологиях я профан и могу ошибаться) HTTP никуда не посылается, а расширяется. Т.к. HTTP изначально задумывался как расширяемый протокол. Расширяется добавляя возможность асинхронно клиенту и серверу обмениваться данными. Это типа, лесом идут всякие Comet'ы, а не HTTP.
Здравствуйте, achmed, Вы писали:
A>Насколько я понял, будет используется команда HTTP CONNECT для установки соединения, которая давно используется для туннелей. A>Кстати, эта команда может быть запрещена настройками proxy.
Да не, вроде GET c Upgrade: WebSocket. Кстати, как раз проблемы с прокси были у всяких там Comet'ов, WebSockets вроде как лишены этого недостатка.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, mkizub, Вы писали:
M>>Что там от HTTP осталось кроме хендшейка?
Y>У меня другой вопрос, а куда все остальное девалось?
/dev/null ?
Было: заголовок (метаданные) + данные, послали, получили ответ, всё.
Стало: открыли соединение, гоняем туда-сюда данные в формате к HTTP отношения не имеющем.
Что общего осталось? А "остальное", что называется, "не пригодилось".
M>Было: заголовок (метаданные) + данные, послали, получили ответ, всё. M>Стало: открыли соединение, гоняем туда-сюда данные в формате к HTTP отношения не имеющем. M>Что общего осталось? А "остальное", что называется, "не пригодилось".
Здравствуйте, Mamut, Вы писали:
M>>Было: заголовок (метаданные) + данные, послали, получили ответ, всё. M>>Стало: открыли соединение, гоняем туда-сюда данные в формате к HTTP отношения не имеющем. M>>Что общего осталось? А "остальное", что называется, "не пригодилось".
M>Вообще-то в HTTP есть до хрена всего полезного, http://webmachine.basho.com/diagram.html и, чувствую, для вебсокетов это все будут заново переизобретать.
Не будут. Соединение уже установлено, никакие access denied или service moved уже не нужны. Ты по сокету гоняешь данные своей аппликухой. Не нужно ради очередных нескольких байт продираться через всю эту диаграмму.
M>>Вообще-то в HTTP есть до хрена всего полезного, http://webmachine.basho.com/diagram.html и, чувствую, для вебсокетов это все будут заново переизобретать.
M>Не будут. Соединение уже установлено, никакие access denied или service moved уже не нужны. Ты по сокету гоняешь данные своей аппликухой. Не нужно ради очередных нескольких байт продираться через всю эту диаграмму.
Вообще-то, та диаграмма не ограничивается только access denied и service moved Это во-первых
Во-вторых, эта диаграмма описывает взаимодействие с ресурсом, а не только с сервером. Установление соединение с сервером не значит, что мы имеем досутп к ресурсу. А это легко и 301 и 406 и 403 и 501 и далее по списку
Здравствуйте, Mamut, Вы писали:
M>Во-вторых, эта диаграмма описывает взаимодействие с ресурсом, а не только с сервером. Установление соединение с сервером не значит, что мы имеем досутп к ресурсу. А это легко и 301 и 406 и 403 и 501 и далее по списку
Всё верно, но ты говоришь в терминах модели HTTP, т.е. stateless разовых запросов.
А web 2.0 — это, фактически, распределённое приложение.
Ты в программе на С и т.п. разве делаешь каждый раз HTTP запрос вместо вызова метода, разве рантайм при вызове метода проходит каждый раз по подобной диаграмме для возврата кода ошибки? Да, где-то есть проверки параметров и состояния, особенно в syscall-ах, но нам же не приходит в голову делать эти проверки всегда и единообразно и на основе HTTP соглашений, верно? Просто не подходит (неудобен, много избыточен, а местами недостаточен) HTTP для реализации распределённого приложения. Он просто от другой модели взаимодействия.
M>>Во-вторых, эта диаграмма описывает взаимодействие с ресурсом, а не только с сервером. Установление соединение с сервером не значит, что мы имеем досутп к ресурсу. А это легко и 301 и 406 и 403 и 501 и далее по списку
M>Всё верно, но ты говоришь в терминах модели HTTP, т.е. stateless разовых запросов. M>А web 2.0 — это, фактически, распределённое приложение. M>Ты в программе на С и т.п. разве делаешь каждый раз HTTP запрос вместо вызова метода, разве рантайм при вызове метода проходит каждый раз по подобной диаграмме для возврата кода ошибки? Да, где-то есть проверки параметров и состояния, особенно в syscall-ах, но нам же не приходит в голову делать эти проверки всегда и единообразно и на основе HTTP соглашений, верно? Просто не подходит (неудобен, много избыточен, а местами недостаточен) HTTP для реализации распределённого приложения. Он просто от другой модели взаимодействия.
Возможно-возможно. В любом случае мы увидим толпу велосипедов по обработке различного рода ошибок
