Здравствуйте, Fox007, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Появился XML протокол. Порт YYY
PD>>При обращении к серверу a.com, поддерживающему XML протокол, надо ему передать некий "приветственный" XML. По порту YYY. PD>>В ответ он , если жив, пришлет XML-ответ (аналог 200 OK)
F>ГОСПОДА! Я КАЖЕТСЯ ПОНЯЛ ЧТО ПАВЕЛ ИМЕЕТ В ВИДУ ПОД ПОНЯТИЕМ "XML-протокол":
Угу, и в результате имеем тот же HTTP, только с более длинным заголовком и content-type обязательно text/xml.
Это если не вспоминать про сжатие и прочее, о чем Синклер уже не раз упоминал.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
M>>В топку такое приложение. Советую взять ближайшую игру и нажать Alt-Tab. Оппаньки фокус потеряли и в игру больше никакой нажатие не передается
PD>Советую сначала нажать Ctrl-Shift, переключиться с русского на английский, потом подумать, как же это получается, несмотря на то, что при этом фокус был неизвестно где, а работает всегда. Потом почитать хотя бы вот это
PD>http://www.rsdn.ru/forum/message/27063.1.aspx
PD>Ну а потом можно поискать здесь насчет драйверов-фильтров, но в этом я не специалист. Там и не такое можно вытворять.
PD>P.S. Не обижайся. Просто ты, видимо, с этими делами незнаком. Всякие WM_KEYDOWN, OnKeyDown, KeyPressed — это очень отдаленные последствия того, что в действительности происходит. И вмешаться можно на очень низком уровне.
Здравствуйте, Fox007, Вы писали:
F>Рискну заявить что такое классическое определение (TCP — транспортный, HTTP — протокол уровня приложения) является верным для приложения, в котором HTTP находится на вершине стека протоколов, то есть приложение, не использующее других протоколов поверх HTTP. К такому приложению относится простейший веб-клиент, не умеющий ничего более чем сделать запрос и получить его результаты, не знающий ничего о самих данных. Однако для веб-приложений, использующих к примеру XML сообщения для общения с сервером, HTTP становится фактически транспортным протоколом, а протоколом уровня приложения становится разработанный программистом веб-приложения сценарий общения клиента и сервера (в данном случае реализованный с помощью XML сообщений).
+1. Именно так оно и есть.
F>Объясни мне на пальцах, каким образом понятие "язык разметки" (XML, CSS, HTML и т.д.) может быть как либо связано с понятием "протокол" (HTTP)???
Объясняю на пальцах.
Протокол — это просто согласованный двумя участниками метод взаимодействия. Вот твой HTTP. Его понимают сервер и клиент HTTP, но не SMTP.
Клиент
GET /a.html HTTP/1.1
и т.д.
Ответ сервера
HTTP/1.1 200 OK
и т.д.
При этом сервер понимает. что ему шлют, а клиент понимает ответы. Ничего больше для протокола не надо. В SMTP это выглядит так
Здравствуйте, Mamut, Вы писали:
M>Еще раз. Зачем мне это в веб-приложении?
Так я уже 10 раз объяснил — не должно быть специальных web-приложений. Должны быть просто приложения, взаимодействующие с Интернет-миром и в то же время умеющие использовать все возможности компьютера.
Тем что заточен конкретно под твоё приложение? Сомнительное преимущество наряду с кучей недостатков в виде изобретания своего собственного нестандартного велосипеда. Если мне придётся когда либо возглавлять разработку
web-приложения группой программистов, под страхом смертной казни запрещю им в подконтрольном мне проекте реализовывать свой транспортный протокол для передачи непотоковых данных, пусть он вдруг даже будет в 1000 раз
лучше HTTP (что сомнительно). HTTP протокол в наше время для прикладного программиста должен быть чёрным ящиком:
с одной стороны компонент типа HTTP::Request с другой — любой из веб-серверов. Как эти вещи работают внутри — не должно иметь принципиального значения для разработки проекта. И тратить ценное время на реализацию этих вещей за деньги заказчика — неуместная роскошь.
Здравствуйте, Mamut, Вы писали:
M>Вот я и говорю, тчо от десктоп приложения это уже не будет отличаться никак
Ну конечно! В 11-й раз — должны быть просто приложения.
Приложение — некий код, выполняющийся на компьютере, устроит такое определение ? Этот код может быть получен на компьютер десятком способов (включая воровство, грабеж и обмен ворованным , быть написан в виде исполняемого кода процессора, байт кода или интерпретироваться a la DOS Basic, обращаться к разным ресурсам Интернета за данными или другим кодом. Все.
Что за прелесть такой аргумент! Если я начну нечто подобное делать, к примеру — на меня надо в суд подать за вредные действия или по крайней мере осудить морально ?
M>>Еще раз. Зачем мне это в веб-приложении?
PD>Так я уже 10 раз объяснил — не должно быть специальных web-приложений. Должны быть просто приложения, взаимодействующие с Интернет-миром и в то же время умеющие использовать все возможности компьютера.
Вам тут уже десять раз объяснили — что такие приложения есть, и делать их никто никому не запрещает. Любое приложение, запущенное на десктопе может "использовать все возможности компьютера и взаимодействовать с интернет-миром".
Но как-то так получается, что веб-приложения делать быстрее, проще, дешевле поддерживать, быстрее распространять, да и пользователям часто оказывается удобно. Когда я могу один и тот-же почтовый ящик посмотреть и с телефона, и со станционарного компьютера, и с маленького eeepc 701, куда просто некуда ставить почтового клиента — это удобно. При этом я не теряю практически ничего. Зачем мне десктопное приложение для этого?
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну и что ? Это аргумент в теоретическом споре ?
WF>Программирование — это инженерия в первую очередь.
Не согласен.
>Поэтому требую спор именовать инженерным.
Требование не принимается. И прав что либо требовать у тебя нет.
<skipped>
dmz>клиент получает от сервера xml. никакого html. сделано поверх http. никакого нового, несуществующего в природе протокола не потребовалось.
Безусловно. Все можно. Можно здесь даже HTTP на SMTP заменить. Хочешь — сделаем. Разве XML нельзя почтой переслать ?
А можно — FTP. Разве XML-файл нельзя по FTP получить ? Получим мы, конечно, протсо файл, ну а потом поймем, что он XML. По расширению, например
А можно еще и по ICQ протоколу. Не пробовал по ICQ слать кусочек XML ? Получится!
Только вот один вопрос остается. XML — это в моей модели просто способ структурирования запроса и ответа. Для универсальности. Если не XML — пожалуйста, я за него не держусь, можно что-то иное. Но мне нужен структурный язык, он же протокол, и не нужен промежуточный носитель — мне и TCP хватит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Fox007, Вы писали:
F>>Рискну заявить что такое классическое определение (TCP — транспортный, HTTP — протокол уровня приложения) является верным для приложения, в котором HTTP находится на вершине стека протоколов, то есть приложение, не использующее других протоколов поверх HTTP. К такому приложению относится простейший веб-клиент, не умеющий ничего более чем сделать запрос и получить его результаты, не знающий ничего о самих данных. Однако для веб-приложений, использующих к примеру XML сообщения для общения с сервером, HTTP становится фактически транспортным протоколом, а протоколом уровня приложения становится разработанный программистом веб-приложения сценарий общения клиента и сервера (в данном случае реализованный с помощью XML сообщений). PD>+1. Именно так оно и есть.
То есть ты уже НЕ утверждаешь (как делал это раньше) что HTTP — протокол уровня приложения и следовательно ставить его в один рад с языком разметки XML бессмысленно?
F>>Объясни мне на пальцах, каким образом понятие "язык разметки" (XML, CSS, HTML и т.д.) может быть как либо связано с понятием "протокол" (HTTP)???
PD>Объясняю на пальцах.
PD>Протокол — это просто согласованный двумя участниками метод взаимодействия. Вот твой HTTP. Его понимают сервер и клиент HTTP, но не SMTP.
Отлично. Ты усвоил понятие "протокол". Теперь осталось отделить остальных мух от котлет.
В своем новоиспечённом протоколе ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML + протокол непосредственно уровня приложения. О вреде придумывания своего транспортного протокола для непоточной передачи данных — смотри моё предыдущее сообщение.
dmz>>но и вредно.
PD>Что за прелесть такой аргумент! Если я начну нечто подобное делать, к примеру — на меня надо в суд подать за вредные действия или по крайней мере осудить морально ?
Подобное делать — это давать право исполняемому с любой странички коду лазить в любые порты и вытворять что угодно? Ю а велкам. Например, вы идете на страничку, с нее грузится код, который ломится в 25-ые порты и рассылает спам, а вы будете крайним. Отличная тема — даже не надо вкладываться в построение ботнетов.
Но боюсь, что подобных вам оригиналов найдется немало, да и файрволлы просто зарубят левые соединения. А в корпоративном мире так вообще, все кроме HTTP(S) закрыто, и не только на уровне портов, а через проксю развязано, так что даже туннелировать ваш протокол через другие порты не получится.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>Еще раз. Зачем мне это в веб-приложении?
PD>Так я уже 10 раз объяснил — не должно быть специальных web-приложений. Должны быть просто приложения, взаимодействующие с Интернет-миром и в то же время умеющие использовать все возможности компьютера.
Есть решения, которые идеально ложатся на веб. Та же экспедия никому нафиг не упала в виде отдельно устанавливаемого приложения (сколько времени мне ждать десктоп приложения от похожего сервиса oneworld под Линукс?).
Есть решения, которые хорошо ложатся на веб. Это, например, работа с электронной почтой (и GMail и Outlook оба хороши)
Есть решения, которые на веб ложатся плохо. Это, например, манипулирование и примитивная обработка фотографий (админская часть flickr'а при все ее крутости — это довольно медленный тормоз)
Есть решения, которые на веб не ложатся вообще — профессиональная работа с аудио/видео/изображения и т.п.
Говорить, что все веб-приложения — отстой, вместо них должны бть только десктоп-приложения так же неверно, как и говорить обратное
PD>А можно — FTP. Разве XML-файл нельзя по FTP получить ? Получим мы, конечно, протсо файл, ну а потом поймем, что он XML. По расширению, например
Да, можно. Только HTTP более удачный транспорт, чем все перечисленные. Кроме того, у него отличная проницаемость через файрволлы.
PD>А можно еще и по ICQ протоколу. Не пробовал по ICQ слать кусочек XML ? Получится!
Можно. А можно через XMPP. Раз уж речь зашла об асинхронности.
PD>Только вот один вопрос остается. XML — это в моей модели просто сп
особ структурирования запроса и ответа. Для универсальности. Если не XML — пожалуйста, я за него не держусь, можно что-то иное. Но мне нужен структурный язык, он же протокол, и не нужен промежуточный носитель — мне и TCP хватит.
Синклер уже сказал, почему не хватит. А когда протокол будет доведен то такого уровня, что хватит, он и будет как HTTP, только будет не ключ:значение, а скобочки треугольные. HTTP — хороший транспорт. Поверх него можно гонять прикладные протоколы с согласованием интерфейсов. Называется SOAP.
M>>Вот я и говорю, тчо от десктоп приложения это уже не будет отличаться никак
PD>Ну конечно! В 11-й раз — должны быть просто приложения.
PD>Приложение — некий код, выполняющийся на компьютере, устроит такое определение ?
На каком компьютере, под управлением какой операционной системы? Что буем делать с мобильными системами?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Только вот один вопрос остается. XML — это в моей модели просто способ структурирования запроса и ответа. Для универсальности. Если не XML — пожалуйста, я за него не держусь, можно что-то иное. Но мне нужен структурный язык, он же протокол, и не нужен промежуточный носитель — мне и TCP хватит.
И в чем же заключается универсальность твоего способа структурирования запроса и ответа? В том что там есть элементы XML с атрибутами вместо plaintextового HTTP и нет "лишних" полей HTTP response? Сомнительное преимущество. Если бы заголовки HTTP в стандарте были прописаны в формате XML, суть протокола HTTP осталась бы та же самая.
Я когда-то был знаком с одним паровозным машинистом. Он водил тяжелые составы, и делал это очень хорошо. Получал премии и висел на Доске Почета. А вот самолетов он в жизни не видел, и , так уж сложилось, ничего о них не знал. И вот однажды я ему рассказал про самолет. Он крепко задумался , и через некоторое время привел мне целый набор аргументов, почему самолет — это плохо. Некоторые из аргументов я приведу
1. Отсуствует топка. Совершенно неясно, куда кидать уголь или дрова.
2. Если кочегар напьется, его надо выматерить и отослать спать. Если пилот напьется, самолет упадет.
3. Бензин ужасно дорог. Дрова намного дешевле.
4. Если при поездке дрова кончатся, их можно нарубить в ближайшем лесу. Где Вы возьмете бензин в воздухе ?
5. Железная дорога строится один раз, потом ей изредка надо ремонт делать. А вам придется каждый раз маршрут и высоту рассчитывать. Где Вы такое количество обслуживающего персонала возьмете, да еще с высокой квалификацией ? А ремонт у нас дядя Вася производит с помощью кувалды и ...
6. Никогда вам не удастся в самолет загрузить столько же груза, сколько в 20-вагонный поезд! Никогда!
7. Пассажиры во время поездки могут на остановках выйти, посмотреть мир и себя показать. Куда вы выйдете в воздухе ?
8. А про нелетную погоду забыли ? А мы всегда ездим!
И т.д.
А может , он прав ? Я вот на майские праздники в поездку собрался, самолетом. Может, пока еще не поздно, паровоз заказать ?