Re[9]: WebSockets и будущее web-программирования
От: yumi  
Дата: 31.12.09 14:18
Оценка: +1
Здравствуйте, mkizub, Вы писали:

M>/dev/null ?


Вряд ли.

M>Было: заголовок (метаданные) + данные, послали, получили ответ, всё.

M>Стало: открыли соединение, гоняем туда-сюда данные в формате к HTTP отношения не имеющем.

И снова переизобретаем все-то, что было в HTTP. Всякие там редиректы, ошибочные ситуации. К тому же, в твоем случае, оно все не стандартизовано, либо заново стандартизуем, либо у нас хаос.

M>Что общего осталось? А "остальное", что называется, "не пригодилось".


Скорее, все осталось и пригодилось. Просто добавилась новая возможность, например, отображать на страничке какие-либо данные в "реальном" времени.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[11]: WebSockets и будущее web-программирования
От: Mamut Швеция http://dmitriid.com
Дата: 01.01.10 15:26
Оценка:
M>>Вообще-то в HTTP есть до хрена всего полезного, http://webmachine.basho.com/diagram.html и, чувствую, для вебсокетов это все будут заново переизобретать.

M>Не будут. Соединение уже установлено, никакие access denied или service moved уже не нужны. Ты по сокету гоняешь данные своей аппликухой. Не нужно ради очередных нескольких байт продираться через всю эту диаграмму.


Вообще-то, та диаграмма не ограничивается только access denied и service moved Это во-первых
Во-вторых, эта диаграмма описывает взаимодействие с ресурсом, а не только с сервером. Установление соединение с сервером не значит, что мы имеем досутп к ресурсу. А это легко и 301 и 406 и 403 и 501 и далее по списку


dmitriid.comGitHubLinkedIn
Re[12]: WebSockets и будущее web-программирования
От: mkizub Литва http://symade.tigris.org
Дата: 04.01.10 11:19
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Во-вторых, эта диаграмма описывает взаимодействие с ресурсом, а не только с сервером. Установление соединение с сервером не значит, что мы имеем досутп к ресурсу. А это легко и 301 и 406 и 403 и 501 и далее по списку


Всё верно, но ты говоришь в терминах модели HTTP, т.е. stateless разовых запросов.
А web 2.0 — это, фактически, распределённое приложение.
Ты в программе на С и т.п. разве делаешь каждый раз HTTP запрос вместо вызова метода, разве рантайм при вызове метода проходит каждый раз по подобной диаграмме для возврата кода ошибки? Да, где-то есть проверки параметров и состояния, особенно в syscall-ах, но нам же не приходит в голову делать эти проверки всегда и единообразно и на основе HTTP соглашений, верно? Просто не подходит (неудобен, много избыточен, а местами недостаточен) HTTP для реализации распределённого приложения. Он просто от другой модели взаимодействия.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[2]: WebSockets и будущее web-программирования
От: mkizub Литва http://symade.tigris.org
Дата: 04.01.10 11:23
Оценка:
Здравствуйте, 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 имеют большое преимущество. Они проще.
Может, конечно, это та простота, которая хуже воровства.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[13]: WebSockets и будущее web-программирования
От: Mamut Швеция http://dmitriid.com
Дата: 04.01.10 11:54
Оценка:
M>>Во-вторых, эта диаграмма описывает взаимодействие с ресурсом, а не только с сервером. Установление соединение с сервером не значит, что мы имеем досутп к ресурсу. А это легко и 301 и 406 и 403 и 501 и далее по списку

M>Всё верно, но ты говоришь в терминах модели HTTP, т.е. stateless разовых запросов.

M>А web 2.0 — это, фактически, распределённое приложение.
M>Ты в программе на С и т.п. разве делаешь каждый раз HTTP запрос вместо вызова метода, разве рантайм при вызове метода проходит каждый раз по подобной диаграмме для возврата кода ошибки? Да, где-то есть проверки параметров и состояния, особенно в syscall-ах, но нам же не приходит в голову делать эти проверки всегда и единообразно и на основе HTTP соглашений, верно? Просто не подходит (неудобен, много избыточен, а местами недостаточен) HTTP для реализации распределённого приложения. Он просто от другой модели взаимодействия.

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


dmitriid.comGitHubLinkedIn
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.