Здравствуйте, mkizub, Вы писали:
M>/dev/null ?
Вряд ли.
M>Было: заголовок (метаданные) + данные, послали, получили ответ, всё.
M>Стало: открыли соединение, гоняем туда-сюда данные в формате к HTTP отношения не имеющем.
И снова переизобретаем все-то, что было в HTTP. Всякие там редиректы, ошибочные ситуации. К тому же, в твоем случае, оно все не стандартизовано, либо заново стандартизуем, либо у нас хаос.
M>Что общего осталось? А "остальное", что называется, "не пригодилось".
Скорее, все осталось и пригодилось. Просто добавилась новая возможность, например, отображать на страничке какие-либо данные в "реальном" времени.
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 для реализации распределённого приложения. Он просто от другой модели взаимодействия.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, mkizub, Вы писали:
M>>Web Sockets Now Available In Google Chrome
MC>А некоторые с xmpp эксперементируют: http://www.process-one.net/en/blogs/article/oneweb_demonstrates_the_power_of_xmpp_inside_the_browser/
С точки зрения модели мной предложенной, WebSockets имеют большое преимущество. Они проще.
Может, конечно, это та простота, которая хуже воровства.
M>>Во-вторых, эта диаграмма описывает взаимодействие с ресурсом, а не только с сервером. Установление соединение с сервером не значит, что мы имеем досутп к ресурсу. А это легко и 301 и 406 и 403 и 501 и далее по списку
M>Всё верно, но ты говоришь в терминах модели HTTP, т.е. stateless разовых запросов.
M>А web 2.0 — это, фактически, распределённое приложение.
M>Ты в программе на С и т.п. разве делаешь каждый раз HTTP запрос вместо вызова метода, разве рантайм при вызове метода проходит каждый раз по подобной диаграмме для возврата кода ошибки? Да, где-то есть проверки параметров и состояния, особенно в syscall-ах, но нам же не приходит в голову делать эти проверки всегда и единообразно и на основе HTTP соглашений, верно? Просто не подходит (неудобен, много избыточен, а местами недостаточен) HTTP для реализации распределённого приложения. Он просто от другой модели взаимодействия.
Возможно-возможно. В любом случае мы увидим толпу велосипедов по обработке различного рода ошибок