Re[27]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 11:14
Оценка:
Здравствуйте, Fox007, Вы писали:

F>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Появился XML протокол. Порт YYY

PD>>При обращении к серверу a.com, поддерживающему XML протокол, надо ему передать некий "приветственный" XML. По порту YYY.

PD>>В ответ он , если жив, пришлет XML-ответ (аналог 200 OK)

F>ГОСПОДА! Я КАЖЕТСЯ ПОНЯЛ ЧТО ПАВЕЛ ИМЕЕТ В ВИДУ ПОД ПОНЯТИЕМ "XML-протокол":


Не совсем.

F>Запрос:

F>
F><get version="1.1">xml://xxx.com/</get>
F>


Сойдет. Как пример.

F>Ответ сервера:


[code]
<response>
<header error="200">

Ну это сойдет.

<cookies>
<cookie id="xxx_session" value="abvgde" />

Это еще большой вопрос, нужны ли они здесь, и если да — то как.

</header>

<body text="<очень_длинная_строка_содержащая тело ответа>"/>


А это еще зачем. А вот так не хочешь ?


<location number="0">
<angle>0.0</angle>
— <rect>
<point x="0" y="0" />
<point x="0" y="896" />
<point x="1760" y="896" />
<point x="1760" y="0" />
</rect>
</location>
With best regards
Pavel Dvorkin
Re[28]: предложите решение
От: Hobot Bobot США  
Дата: 03.04.08 11:18
Оценка: +2
Угу, и в результате имеем тот же 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!
Re[28]: предложите решение
От: Mamut Швеция http://dmitriid.com
Дата: 03.04.08 11:24
Оценка:
M>>В топку такое приложение. Советую взять ближайшую игру и нажать Alt-Tab. Оппаньки фокус потеряли и в игру больше никакой нажатие не передается

PD>Советую сначала нажать Ctrl-Shift, переключиться с русского на английский, потом подумать, как же это получается, несмотря на то, что при этом фокус был неизвестно где, а работает всегда. Потом почитать хотя бы вот это


PD>http://www.rsdn.ru/forum/message/27063.1.aspx
Автор: Trantor
Дата: 06.02.02


PD>Ну а потом можно поискать здесь насчет драйверов-фильтров, но в этом я не специалист. Там и не такое можно вытворять.


PD>P.S. Не обижайся. Просто ты, видимо, с этими делами незнаком. Всякие WM_KEYDOWN, OnKeyDown, KeyPressed — это очень отдаленные последствия того, что в действительности происходит. И вмешаться можно на очень низком уровне.



Еще раз. Зачем мне это в веб-приложении?
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[27]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 11:37
Оценка:
Здравствуйте, 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 это выглядит так

Клиент

MAIL FROM : <aaa@abc.com>

Server :

250 OK

и т.д.

В протоколе, что я предлагаю,

Клиент :

<?xml version="1.0" encoding="ISO-8859-1"?>
<rect> location = "return"
</rect>

Сервер

<?xml version="1.0" encoding="ISO-8859-1"?>
<location>
<point x="0" y="0" />
<point x="0" y="896" />
<point x="1760" y="896" />
<point x="1760" y="0" />
</location>

Сервер понял, что от него затребовали location (АПИ вызов "return". В ответ он ее и вернул.

Разумееется, в реальном запросе и на входе будет больше параметров, и результат будет посложнее.
With best regards
Pavel Dvorkin
Re[29]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 11:39
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Еще раз. Зачем мне это в веб-приложении?


Так я уже 10 раз объяснил — не должно быть специальных web-приложений. Должны быть просто приложения, взаимодействующие с Интернет-миром и в то же время умеющие использовать все возможности компьютера.
With best regards
Pavel Dvorkin
Re[28]: предложите решение
От: Fox007 Россия http://nalobin.ru
Дата: 03.04.08 11:40
Оценка: +2
PD><body text="<очень_длинная_строка_содержащая тело ответа>"/>


PD>А это еще зачем. А вот так не хочешь ?

PD> <location number="0">
PD> <angle>0.0</angle>
PD>- <rect>
PD> <point x="0" y="0" />
PD> <point x="0" y="896" />
PD> <point x="1760" y="896" />
PD> <point x="1760" y="0" />
PD> </rect>
PD> </location>

Собственно, а чем ответ твоего "протокола" лучше нежели обыкновенный HTTP reponse:

HTTP/1.1 200 OK
Date: Fri, 12 Oct 2007 04:10:33 GMT
Server: Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8e mod_perl/2.0.3 Perl/v5.8.8
Accept-Ranges: bytes
Connection: close
Content-Type: text/xml

<location number="0">
<angle>0.0</angle>
<rect>
<point x="0" y="0" />
<point x="0" y="896" />
<point x="1760" y="896" />
<point x="1760" y="0" />
</rect>
</location>


Тем что заточен конкретно под твоё приложение? Сомнительное преимущество наряду с кучей недостатков в виде изобретания своего собственного нестандартного велосипеда. Если мне придётся когда либо возглавлять разработку
web-приложения группой программистов, под страхом смертной казни запрещю им в подконтрольном мне проекте реализовывать свой транспортный протокол для передачи непотоковых данных, пусть он вдруг даже будет в 1000 раз
лучше HTTP (что сомнительно). HTTP протокол в наше время для прикладного программиста должен быть чёрным ящиком:
с одной стороны компонент типа HTTP::Request с другой — любой из веб-серверов. Как эти вещи работают внутри — не должно иметь принципиального значения для разработки проекта. И тратить ценное время на реализацию этих вещей за деньги заказчика — неуместная роскошь.
Re[28]: предложите решение
От: dmz Россия  
Дата: 03.04.08 11:44
Оценка: +3
PD>А это еще зачем. А вот так не хочешь ?

Чем это принципиально отличается от:

Date    Thu, 03 Apr 2008 11:37:59 GMT
Server    WSGIServer/0.1 Python/2.5.1
Content-Type    text/xml
Request Headers
Host    localhost:8080
User-Agent    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13
Accept    application/xml, text/xml, */*
Accept-Language    en-us,en;q=0.5
Accept-Encoding    gzip,deflate
Accept-Charset    ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive    300
Connection    keep-alive
Content-Type    application/x-www-form-urlencoded
X-Requested-With    XMLHttpRequest
Referer    http://localhost:8080/events
Content-Length    19
Cookie    logistics-ssid=20f6fa3758a4164d71424d10b37728e0
Pragma    no-cache
Cache-Control    no-cache

<?xml version="1.0"?>
<data>
  <total-pages>1</total-pages>
  <current-page>0</current-page>
  <events>
    <item class="Row">
      <received type="datetime" year="2008" month="3" day="26" hour="20" minute="30" second="3">2008-03-26 20:30:03.278902</received>
      <severity>1</severity>
      <type-id>1</type-id>
      <event-type-name>no_answer</event-type-name>
      <object-id>297</object-id>
      <unit-uid>10</unit-uid>
      <object-identity>99-99-99</object-identity>
      <id>108</id>
    </item>
  </events>
</data>


клиент получает от сервера xml. никакого html. сделано поверх http. никакого нового, несуществующего в природе протокола не потребовалось.
Re[3]: Я понял!!!!
От: Pavel Dvorkin Россия  
Дата: 03.04.08 11:45
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Вот я и говорю, тчо от десктоп приложения это уже не будет отличаться никак


Ну конечно! В 11-й раз — должны быть просто приложения.

Приложение — некий код, выполняющийся на компьютере, устроит такое определение ? Этот код может быть получен на компьютер десятком способов (включая воровство, грабеж и обмен ворованным , быть написан в виде исполняемого кода процессора, байт кода или интерпретироваться a la DOS Basic, обращаться к разным ресурсам Интернета за данными или другим кодом. Все.
With best regards
Pavel Dvorkin
Re[4]: Я понял!!!!
От: Pavel Dvorkin Россия  
Дата: 03.04.08 11:47
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>но и вредно.


Что за прелесть такой аргумент! Если я начну нечто подобное делать, к примеру — на меня надо в суд подать за вредные действия или по крайней мере осудить морально ?
With best regards
Pavel Dvorkin
Re[30]: предложите решение
От: dmz Россия  
Дата: 03.04.08 11:48
Оценка: +3
M>>Еще раз. Зачем мне это в веб-приложении?

PD>Так я уже 10 раз объяснил — не должно быть специальных web-приложений. Должны быть просто приложения, взаимодействующие с Интернет-миром и в то же время умеющие использовать все возможности компьютера.


Вам тут уже десять раз объяснили — что такие приложения есть, и делать их никто никому не запрещает. Любое приложение, запущенное на десктопе может "использовать все возможности компьютера и взаимодействовать с интернет-миром".

Но как-то так получается, что веб-приложения делать быстрее, проще, дешевле поддерживать, быстрее распространять, да и пользователям часто оказывается удобно. Когда я могу один и тот-же почтовый ящик посмотреть и с телефона, и со станционарного компьютера, и с маленького eeepc 701, куда просто некуда ставить почтового клиента — это удобно. При этом я не теряю практически ничего. Зачем мне десктопное приложение для этого?
Re[29]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 11:49
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Ну и что ? Это аргумент в теоретическом споре ?


WF>Программирование — это инженерия в первую очередь.


Не согласен.

>Поэтому требую спор именовать инженерным.


Требование не принимается. И прав что либо требовать у тебя нет.
With best regards
Pavel Dvorkin
Re[29]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 11:56
Оценка:
Здравствуйте, dmz, Вы писали:


dmz>Чем это принципиально отличается от:


<skipped>

dmz>клиент получает от сервера xml. никакого html. сделано поверх http. никакого нового, несуществующего в природе протокола не потребовалось.


Безусловно. Все можно. Можно здесь даже HTTP на SMTP заменить. Хочешь — сделаем. Разве XML нельзя почтой переслать ?

А можно — FTP. Разве XML-файл нельзя по FTP получить ? Получим мы, конечно, протсо файл, ну а потом поймем, что он XML. По расширению, например

А можно еще и по ICQ протоколу. Не пробовал по ICQ слать кусочек XML ? Получится!

Только вот один вопрос остается. XML — это в моей модели просто способ структурирования запроса и ответа. Для универсальности. Если не XML — пожалуйста, я за него не держусь, можно что-то иное. Но мне нужен структурный язык, он же протокол, и не нужен промежуточный носитель — мне и TCP хватит.
With best regards
Pavel Dvorkin
Re[28]: предложите решение
От: Fox007 Россия http://nalobin.ru
Дата: 03.04.08 11:56
Оценка:
Здравствуйте, 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.


Отлично. Ты усвоил понятие "протокол". Теперь осталось отделить остальных мух от котлет.


PD>В протоколе, что я предлагаю,


PD>Клиент :


PD><?xml version="1.0" encoding="ISO-8859-1"?>

PD><rect> location = "return"
PD></rect>

PD>Сервер


PD><?xml version="1.0" encoding="ISO-8859-1"?>

PD><location>
PD> <point x="0" y="0" />
PD> <point x="0" y="896" />
PD> <point x="1760" y="896" />
PD> <point x="1760" y="0" />
PD></location>

В своем новоиспечённом протоколе ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML + протокол непосредственно уровня приложения. О вреде придумывания своего транспортного протокола для непоточной передачи данных — смотри моё предыдущее сообщение.
Re[5]: Я понял!!!!
От: dmz Россия  
Дата: 03.04.08 11:58
Оценка: +2
dmz>>но и вредно.

PD>Что за прелесть такой аргумент! Если я начну нечто подобное делать, к примеру — на меня надо в суд подать за вредные действия или по крайней мере осудить морально ?


Подобное делать — это давать право исполняемому с любой странички коду лазить в любые порты и вытворять что угодно? Ю а велкам. Например, вы идете на страничку, с нее грузится код, который ломится в 25-ые порты и рассылает спам, а вы будете крайним. Отличная тема — даже не надо вкладываться в построение ботнетов.

Но боюсь, что подобных вам оригиналов найдется немало, да и файрволлы просто зарубят левые соединения. А в корпоративном мире так вообще, все кроме HTTP(S) закрыто, и не только на уровне портов, а через проксю развязано, так что даже туннелировать ваш протокол через другие порты не получится.
Re[29]: предложите решение
От: Fox007 Россия http://nalobin.ru
Дата: 03.04.08 11:59
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Чем это принципиально отличается от:

Ха, вот я и о том же
Re[30]: предложите решение
От: Mamut Швеция http://dmitriid.com
Дата: 03.04.08 12:04
Оценка: +3
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Mamut, Вы писали:


M>>Еще раз. Зачем мне это в веб-приложении?


PD>Так я уже 10 раз объяснил — не должно быть специальных web-приложений. Должны быть просто приложения, взаимодействующие с Интернет-миром и в то же время умеющие использовать все возможности компьютера.



Есть решения, которые идеально ложатся на веб. Та же экспедия никому нафиг не упала в виде отдельно устанавливаемого приложения (сколько времени мне ждать десктоп приложения от похожего сервиса oneworld под Линукс?).

Есть решения, которые хорошо ложатся на веб. Это, например, работа с электронной почтой (и GMail и Outlook оба хороши)

Есть решения, которые на веб ложатся плохо. Это, например, манипулирование и примитивная обработка фотографий (админская часть flickr'а при все ее крутости — это довольно медленный тормоз)

Есть решения, которые на веб не ложатся вообще — профессиональная работа с аудио/видео/изображения и т.п.

Говорить, что все веб-приложения — отстой, вместо них должны бть только десктоп-приложения так же неверно, как и говорить обратное
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[30]: предложите решение
От: dmz Россия  
Дата: 03.04.08 12:05
Оценка:
PD>А можно — FTP. Разве XML-файл нельзя по FTP получить ? Получим мы, конечно, протсо файл, ну а потом поймем, что он XML. По расширению, например

Да, можно. Только HTTP более удачный транспорт, чем все перечисленные. Кроме того, у него отличная проницаемость через файрволлы.

PD>А можно еще и по ICQ протоколу. Не пробовал по ICQ слать кусочек XML ? Получится!


Можно. А можно через XMPP. Раз уж речь зашла об асинхронности.

PD>Только вот один вопрос остается. XML — это в моей модели просто сп

особ структурирования запроса и ответа. Для универсальности. Если не XML — пожалуйста, я за него не держусь, можно что-то иное. Но мне нужен структурный язык, он же протокол, и не нужен промежуточный носитель — мне и TCP хватит.

Синклер уже сказал, почему не хватит. А когда протокол будет доведен то такого уровня, что хватит, он и будет как HTTP, только будет не ключ:значение, а скобочки треугольные. HTTP — хороший транспорт. Поверх него можно гонять прикладные протоколы с согласованием интерфейсов. Называется SOAP.

Где тут место вашему протоколу?
Re[4]: Я понял!!!!
От: Mamut Швеция http://dmitriid.com
Дата: 03.04.08 12:09
Оценка:
M>>Вот я и говорю, тчо от десктоп приложения это уже не будет отличаться никак

PD>Ну конечно! В 11-й раз — должны быть просто приложения.


PD>Приложение — некий код, выполняющийся на компьютере, устроит такое определение ?



На каком компьютере, под управлением какой операционной системы? Что буем делать с мобильными системами?
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[30]: предложите решение
От: Fox007 Россия http://nalobin.ru
Дата: 03.04.08 12:09
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Только вот один вопрос остается. XML — это в моей модели просто способ структурирования запроса и ответа. Для универсальности. Если не XML — пожалуйста, я за него не держусь, можно что-то иное. Но мне нужен структурный язык, он же протокол, и не нужен промежуточный носитель — мне и TCP хватит.


И в чем же заключается универсальность твоего способа структурирования запроса и ответа? В том что там есть элементы XML с атрибутами вместо plaintextового HTTP и нет "лишних" полей HTTP response? Сомнительное преимущество. Если бы заголовки HTTP в стандарте были прописаны в формате XML, суть протокола HTTP осталась бы та же самая.
Re: недостатки самолета
От: Pavel Dvorkin Россия  
Дата: 03.04.08 12:18
Оценка: -1 :)))
Я когда-то был знаком с одним паровозным машинистом. Он водил тяжелые составы, и делал это очень хорошо. Получал премии и висел на Доске Почета. А вот самолетов он в жизни не видел, и , так уж сложилось, ничего о них не знал. И вот однажды я ему рассказал про самолет. Он крепко задумался , и через некоторое время привел мне целый набор аргументов, почему самолет — это плохо. Некоторые из аргументов я приведу

1. Отсуствует топка. Совершенно неясно, куда кидать уголь или дрова.
2. Если кочегар напьется, его надо выматерить и отослать спать. Если пилот напьется, самолет упадет.
3. Бензин ужасно дорог. Дрова намного дешевле.
4. Если при поездке дрова кончатся, их можно нарубить в ближайшем лесу. Где Вы возьмете бензин в воздухе ?
5. Железная дорога строится один раз, потом ей изредка надо ремонт делать. А вам придется каждый раз маршрут и высоту рассчитывать. Где Вы такое количество обслуживающего персонала возьмете, да еще с высокой квалификацией ? А ремонт у нас дядя Вася производит с помощью кувалды и ...
6. Никогда вам не удастся в самолет загрузить столько же груза, сколько в 20-вагонный поезд! Никогда!
7. Пассажиры во время поездки могут на остановках выйти, посмотреть мир и себя показать. Куда вы выйдете в воздухе ?
8. А про нелетную погоду забыли ? А мы всегда ездим!

И т.д.

А может , он прав ? Я вот на майские праздники в поездку собрался, самолетом. Может, пока еще не поздно, паровоз заказать ?

P.S. Просьба не принимать все сказанное всерьез.
With best regards
Pavel Dvorkin
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.