Re[3]: предложите решение
От: Left2 Украина  
Дата: 03.04.08 09:54
Оценка: +1
Много читал и не понял чем это вообще отличается от существующей ситуации в вебе. Тем что вместо HTTP ты предлагаешь TCP-IP? Так тебе уже много раз сказали здесь о том что сути дела это не меняет, к тому же выгоды от перехода к более низкоуровневому протоколу в большинстве случаев не перевешивают недостатков.

PD>1. Skype. Бесспорно, десктопное приложение. В то же время очевидно, что это Интернет приложение. Вот что мне сейчас tcpview о нем показал


PD>Skype.exe:1040 TCP divsoft:60801 117.8.238.206:4020 ESTABLISHED

PD>Skype.exe:1040 TCP divsoft:60801 154.business-link-static.sovintel.spb.ru:60721 ESTABLISHED
PD>Skype.exe:1040 TCP divsoft:1609 83.167.103.156:13915 ESTABLISHED
PD>Skype.exe:1040 TCP divsoft:60801 divsoft:0 LISTENING
PD>Skype.exe:1040 TCP divsoft:60801 fat.omsk.ru:1212 ESTABLISHED
PD>Skype.exe:1040 TCP divsoft:60801 host-195-49-170-70.avantel.ru:50941 ESTABLISHED

PD>Чего ему на 154.business-link-static.sovintel.spb.ru или host-195-49-170-70.avantel.ru нужно — понятия не имею. Может, эти хосты и не связаны логически, то есть с каждым он работает независимо. Может, он комбирирует данные полученные от них. Не знаю. Но работает он именно по этой модели, хотя XML тут или что-то иное — не знаю.


Ты бы почитал общедоступную информацию о скайпе. На эти хосты он ломится потому, что там стоят его "опорные точки". У него нет выделенного сервера как такового вообще. Он с тем же успехом может ломиться на соседнюю машину, если скайп на соседней машине решит что машина подходит под роль "опорной точки".

PD>4. Ну и последнее. То, чем я сейчас занят. Если в общем виде — некая система взаимодействующих серверов и клиентов с протоколом их взаимодействия. Увы, бинарным пока что. Вот мы и учим эту систему XML понимать, чтобы новые серверы/клиенты могли с прежней системой взаимодействовать. Никаким HTTP там и не пахнет. Подробностей не будет.


Твоя ненависть к HTTP скорее всего от непонимания того что протокол этот вовсе не обязан заниматься только пересылкой форм "туда и обратно".
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[3]: информация для всех моих оппонентов
От: Pavel Dvorkin Россия  
Дата: 03.04.08 09:59
Оценка:
1. У меня уже сил нет. Отвечать всем сразу — никаких сил не хватит. Так что сегодня отвечать больше не буду.
2. У меня завтра занятия с утра до вечера, так что либо тоже не буду, либо поздно вечером.
3. В выходные я всегда вне Интернета.
4. Участвовать в этой дискуссии я мог лишь потому, что главный заказчик уехал в отпуск, а без него никто не решается сказать, что будем дальше делать. В понедельник он должен вернуться. Так что если в понедельник меня озадачат — смогу дать лишь короткие ответы.
5. Если кто-то хочет критиковать — критикуйте в ответ на родительское к этому сообщение. Отвечать на то, что будет написано в остальных ветвях, я не буду — по причине п.1-4.
With best regards
Pavel Dvorkin
Re[3]: предложите решение
От: Mamut Швеция http://dmitriid.com
Дата: 03.04.08 10:07
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Так, ладно. Я уже не в силах отвечать всем, так что изложу свое видение и на этом на сегодня закончу. Собственно, я его уже изложил.


PD>>Решение с клиентом


PD>>Клиент выдает на экран форму, в которой запрашивается название продукта и адрес получателя. Эта форма не получена ни с a.com, ни c b.com, а просто принадлежит клиентному приложению. После нажатия Submit клиентное приложение берет название и отправляет серверу a.com. Получив ответ от него, оно берет полученные данные, добавляет к ним адрес получателя и шлет серверу b.com. Полученный от него ответ возвращается пользователю.


PD>Немного уточню.


PD>Предварительно еще раз напоминаю — речь идет об архитектуре. О том, правильная она или нет. Правктические соображения, все вместе взятые, весьма существенны, но мы-то все же об архитектуре спор этот затеяли. Так что вопросы стоимости и т.д. я не рассматриваю.


PD>Итак.


PD>Клиент выдает на экран форму, в которой запрашивается название продукта и адрес получателя. Клиент — либо EXE, либо JAR либо не знаю что еще.


Пользовател зашел на страницу Expedia, увидел форму, которая отсылает данные на сервер


PD>Серверы имеют свой АПИ. Этот АПИ создается одновременно с созданием сервера. Этот АПМ базируется на XML (к примеру) и позволяет формировать те или иные запросы к серверу. При этом серверу передается только XML, в котором полностью и описывается запрос. Сервер также умеет возвращать XML с описанием своего АПИ. (В скобках — сервер, возможно, дает еще и утилиту API Builder)


Сервер Expedia помимо того, что уже умеет возвращать данные обратно клиенту в виде HTML, также может обращаться к другим серверам, каждый из которых имеет свой АПИ, который создается одновременно с созданием того или иного сервера

PD>Этот АПИ может расширяться, может и сужаться, но всегда остается в консистентном состоянии. Аналогично Win32 API, который хоть и не раз изменялся, но все же при этом прежние возможности либо продолжают поддерживаться (в большинстве случаев), либо объявляются deprecated и реально исполянются другой частью АПИ, либо отменяются, в последнем случае сервер при попытке вызвать этот АПИ возвращает отказ.


АПИ внешних по отношению к expedia серверов могут расширяться и сужаться и при этом может не оставться в конистентном состоянии (например недавно Amazon сменила апи для своего ECS, выпустив версию 3, версия 2 объявлена более неподдерживаемой — здесь никакой десктоп клиент не поможет, его все равно придется переписывать)

PD>Для работы с этим АПИ используется некий XML протокол поверх TCP. Для обращения к серверу единственное, что надо знать — его имя. Далее ему шлется некий XML с запросом, он шлет XML с ответом и т.д. Никакого знания о внутреннем устройстве сервера вовне не дается, так что его можно переносить на другую платформу или вообще полностью переработать. Никакие явные ссылки на внутренность сервера не существуют. Необходимо только поддерживать АПИ.


Для работы с срверами, внешними к Expedia, используются протоколы и форматы данных, определенные этими серверами, например EDIFACT (описание)


PD>Клиент либо уже работал с этим сервером, либо нет. Если нет — он первым делом запрашивает его АПИ. Возможно АПИ будет достаточно сложным или многоуровневым, так что детали здесь требуют уточнения. Но для большинства коммерческих сайтов он слишком сложным не будет. Например, сайт туроператора. Запросы могут быть по странам, датам, отелям, самолетам и т.д. Ничего в приницпе тут нового нет и не будет, а если что-то поменяется — будет новая версия АПИ при том. что старая поддерживается.


И что делает клиент с этим апи? Он автоматом знает, что с ним делать? Бред. Такого нет даже теоретически

PD>Если клиент имеет АПИ, он строит на его основе запрос к серверу. Это может быть сделано даже автоматически, так как АПИ разных серверов хоть и различен, но в основе его лежит унифицированный формат, XML, так что пострение запроса , в общем, может делаться одним или почти одним и тем же способом.


Сказки

PD>Сервер, получив запрос на родном ему АПИ, исполняет этот запрос. Если при этом возникают ошибки, он изготавливает ответ с XML, содержащем описание ошибки. В противном случае он возвращает XML с ответом.


Сервер Expedia, получив ответ с внешних серверов в иде XML, EDIFACT или дваоичных данных, подготавливает их для отображения и отсылает пользователю

PD>Я прекрасно понимаю, что реальных шансов на широкомасшатбный переход к этой модели нет в ближайшем будущем. Я прекрасно вижу всякие стоимостные проблемы, проблемы безопасности и т.д. Но ведь мы архитектуру обсуждаем, не так ли. Поэтому прошу именно архитектуру и критиковать.


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


PD>4. Ну и последнее. То, чем я сейчас занят. Если в общем виде — некая система взаимодействующих серверов и клиентов с протоколом их взаимодействия. Увы, бинарным пока что. Вот мы и учим эту систему XML понимать, чтобы новые серверы/клиенты могли с прежней системой взаимодействовать. Никаким HTTP там и не пахнет. Подробностей не будет.


Веб интерфейс у это системы будет? Если будет, то веб-интерфейсу будет абсолютно все равно, в каком формате его сервер будет общаться с другими серверами
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[4]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 10:08
Оценка:
Здравствуйте, Left2, Вы писали:


L>Твоя ненависть к HTTP скорее всего от непонимания того что протокол этот вовсе не обязан заниматься только пересылкой форм "туда и обратно".


Без комментариев — кусочек моего кода


      WebClient myWebClient = new WebClient();
      try {
    myDataBuffer = myWebClient.DownloadData (URL);
    // Display the downloaded data.

 // ну и т.д.
With best regards
Pavel Dvorkin
Re[4]: информация для всех моих оппонентов
От: dmz Россия  
Дата: 03.04.08 10:10
Оценка: +2
PD>5. Если кто-то хочет критиковать — критикуйте в ответ на родительское к этому сообщение. Отвечать на то, что будет написано в остальных ветвях, я не буду — по причине

Да тут нечего критиковать. Если у вас стоит задача интегрировать свои серверы/сервисы, и вы будете изобретать свой протокол вместо того, что бы взять SOAP/XMLRPC/REST/XMPP — просто распишитесь в некомпетентности, и все. Передавайте привет заказчику.

Остальное даже обсуждать бессмысленно — все предложенные "новации" давно есть. Штука не в том, как поиметь универсальный протокол или API,
штука в том, как заставить владельцев пресловутых a.com его предоставить (ответ — никак, если они этого не хотят).
Re[26]: предложите решение
От: Fox007 Россия http://nalobin.ru
Дата: 03.04.08 10:13
Оценка: 4 (1) +2
F>>HTTP — транспортный протокол.
PD>Первый раз такое слыщу. Я как-то считал, что транспортным является TCP, а HTTP — протокол уровня приложения.
Рискну заявить что такое классическое определение (TCP — транспортный, HTTP — протокол уровня приложения) является верным для приложения, в котором HTTP находится на вершине стека протоколов, то есть приложение, не использующее других протоколов поверх HTTP. К такому приложению относится простейший веб-клиент, не умеющий ничего более чем сделать запрос и получить его результаты, не знающий ничего о самих данных. Однако для веб-приложений, использующих к примеру XML сообщения для общения с сервером, HTTP становится фактически транспортным протоколом, а протоколом уровня приложения становится разработанный программистом веб-приложения сценарий общения клиента и сервера (в данном случае реализованный с помощью XML сообщений).

>>XML — язык разметки. Поэтому то и нет XML протокола поверх TCP/IP. Он вообще НЕ протокол.

PD>Он — не протокол, верно. Но что мешало сделать его протоколом на том же уровне, что и HTTP, FTP, SMTP... ?
Объясни мне на пальцах, каким образом понятие "язык разметки" (XML, CSS, HTML и т.д.) может быть как либо связано с понятием "протокол" (HTTP)???
Re[5]: предложите решение
От: Hobot Bobot США  
Дата: 03.04.08 10:20
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Без комментариев — кусочек моего кода


Ни о чем не говорящий кусок кода, по-моему. Рассуждения о том, что "XML лучше HTTP", на мой взгляд, куда более показательны.
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[3]: предложите решение
От: Hobot Bobot США  
Дата: 03.04.08 10:24
Оценка:
Немного подумав, решил дополнить.

Вы начинаете говорить об архитектуре клиента и со второго же предложения переходите на архитектру серверов a и b. Это не совсем корректно — изначально речь шла о том, что эти сервера существуют сами по себе, нам не подчиняются и о существовании клиентов не знают и знать не хотят, разве нет?
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: еще раз о web-приложениях
От: hattab  
Дата: 03.04.08 10:24
Оценка: :))
Здравствуйте, Pavel Dvorkin

Парни! Вы о другом поспорьте: вот есть два сервиса a.com и b.com, они большие (ну, как гугль пусть . И вот Синклер с Мамутом делают сервис c.com -- получается мэшап(!!!вебдваноль!!!), и хостят его где нибудь за недорого (ну, они же не гугль). Сервис становится популярным. Очень. Ресурсы хостера, на котором живет c.com конечны, разумеется, и это значит, что c.com будет очень часто лежать в дауне (ну или очень изредка из него подниматься) до тех пор пока хостер их пинками не выгонит за превышение квот. Все пользователи от такой любви убегут на бесплатный клиент Дворкина, который и у автора много времени не отнимает и работу свою работает. Вот. Теперь спорьте
Re[2]: еще раз о web-приложениях
От: Hobot Bobot США  
Дата: 03.04.08 10:28
Оценка: +2 :)
Здравствуйте, hattab, Вы писали:

H>И вот Синклер с Мамутом делают сервис c.com -- получается мэшап(!!!вебдваноль!!!), и хостят его где нибудь за недорого (ну, они же не гугль). Сервис становится популярным. Очень.


После чего Синклер с Мамутом его продают. Задорого. Или наоборот, зарабатывают много денег, переносят c.com в свой собственный data center, а со временем покупают a и b.
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[26]: предложите решение
От: Fox007 Россия http://nalobin.ru
Дата: 03.04.08 10:29
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Появился XML протокол. Порт YYY

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

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

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

Запрос:
<get version="1.1">xml://xxx.com/</get>


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

<response>
<header error="200">
<cookies>
 <cookie id="xxx_session" value="abvgde" />
 ...
</cookies>
</header>

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


Конечно же это совсем не похоже на HTTP, это абсолютно новый и очень функциональный протокол в отличие от HTTP!
Я понял!!!!
От: Mamut Швеция http://dmitriid.com
Дата: 03.04.08 10:32
Оценка:
Я наконец-то понял в чем дело

Павел хочет, чтобы с веб-страницы можно было выполнять запросы по любому произвольному протоколу.

То есть сейчас общение веб-страница <-> сервер ограничено HTTP и общением поверх HTTP. Павел хочет, чтобы с веб страницы можно было бы делать все то же, что и из полноценного десктоп-приложения — открывать произвольные порты, писать в них и читать из них любым протоколм, определенным программистом, принимать и отсылать произвольные данные и т.п.

В этом случае мы будем иметь на руках все то же десктоп-приложение с теми же проблемами и преимуществами.

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


dmitriid.comGitHubLinkedIn
Re[6]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 10:34
Оценка:
Здравствуйте, Hobot Bobot, Вы писали:

HB>Ни о чем не говорящий кусок кода, по-моему.


Просто к вопросу о том. что я "не понимаю того что протокол этот вовсе не обязан заниматься только пересылкой форм "туда и обратно"
With best regards
Pavel Dvorkin
Re[2]: еще раз о web-приложениях
От: dmz Россия  
Дата: 03.04.08 10:39
Оценка: +4 :)
H>Парни! Вы о другом поспорьте: вот есть два сервиса a.com и b.com, они большие (ну, как гугль пусть . И вот Синклер с Мамутом делают сервис c.com -- получается мэшап(!!!вебдваноль!!!), и хостят его где нибудь за недорого (ну, они же не гугль). Сервис становится популярным. Очень. Ресурсы хостера, на котором живет c.com конечны, разумеется, и это значит, что c.com будет очень часто лежать в дауне (ну или очень изредка из него подниматься) до тех пор пока хостер их пинками не выгонит за превышение квот. Все пользователи от такой любви убегут на бесплатный клиент Дворкина, который и у автора много времени не отнимает и работу свою работает. Вот. Теперь спорьте

Фигня какая-то. Сервер мы напишем на эрланге, и развернем на кластере из пятка машин. Когда клиентов станет столько, что кластер станет плохо, это будет значить, что нас совершенно немвеняемое количество клиентов, и Гугл с остальными уже стоят в очереди, что бы нас купить, а инвестор отвалил денег еще на пару сотен серверов для кластера.

Тем временем Дворкин будет все еще писать своего бесплатного клиента; потом он его напишет; сколько-то народи не осилят его скачать, сколько-то не осилят его запустить, потому что дотнет не той системы установлен или прав недостаточно; Потом a, b или c что-нибудь поменяют в своих интерфейсах, и клиент перестанет работать и надо будет срочно его обновить, с чем тоже справятся далеко не все. Пока написанный апдейт разойдется, a b или c опять что-то поменяют в интерфейсах, и все пойдет по новой. Пользователи тем временем забьют.
Re[3]: предложите решение
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.04.08 10:41
Оценка: 17 (3) +4
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Предварительно еще раз напоминаю — речь идет об архитектуре. О том, правильная она или нет. Правктические соображения, все вместе взятые, весьма существенны, но мы-то все же об архитектуре спор этот затеяли. Так что вопросы стоимости и т.д. я не рассматриваю.


PD>Итак.

Ок, несколько несущественных комментариев приведены в тексте.
PD>Клиент выдает на экран форму, в которой запрашивается название продукта и адрес получателя. Клиент — либо EXE, либо JAR либо не знаю что еще.

PD>Серверы имеют свой АПИ. Этот АПИ создается одновременно с созданием сервера. Этот АПМ базируется на XML (к примеру) и позволяет формировать те или иные запросы к серверу. При этом серверу передается только XML, в котором полностью и описывается запрос. Сервер также умеет возвращать XML с описанием своего АПИ. (В скобках — сервер, возможно, дает еще и утилиту API Builder)

Ок. Схема "описания АПИ" — фиксированная, или она будет расширяться?

PD>Этот АПИ может расширяться, может и сужаться, но всегда остается в консистентном состоянии. Аналогично Win32 API, который хоть и не раз изменялся, но все же при этом прежние возможности либо продолжают поддерживаться (в большинстве случаев), либо объявляются deprecated и реально исполянются другой частью АПИ, либо отменяются, в последнем случае сервер при попытке вызвать этот АПИ возвращает отказ.

Вопрос: кто читает "описание АПИ"? Клиент обязан перед каждым вызовом прочитать описание? Или он полагается на знание API, которое в него заложил программист при написании клиента?
Если клиент читает это описание, то что он с ним делает? Это слишком общий вопрос, так что я уточню. Допустим, описание API говорило, что клиент может отправить XML с определенным XSD, и в ответ получит другой XML с другим XSD.
Теперь описание говорит, что в ответ клиент получит XML, соответствующий некоторой другой XSD-схеме. Может ли клиент сделать что-то полезное, или ему придется аварийно завершиться, сообщив пользователю protocol version mismatch?

PD>Для работы с этим АПИ используется некий XML протокол поверх TCP. Для обращения к серверу единственное, что надо знать — его имя.

Как предполагается определять порт, с которым надо установить соединение? (по имени, очевидно, можно получить только IP адрес).
PD>Далее ему шлется некий XML с запросом, он шлет XML с ответом и т.д. Никакого знания о внутреннем устройстве сервера вовне не дается, так что его можно переносить на другую платформу или вообще полностью переработать. Никакие явные ссылки на внутренность сервера не существуют. Необходимо только поддерживать АПИ.
После отправки ответа соединение закрывается или остается открытым для приема следующего запроса?
Как предполагается выполнять аутентикацию в рамках этого АПИ?
Поддерживается ли сжатие? Как клиент договаривается с сервером об используемом алгоритме компрессии?
Поддерживается ли шифрование трафика? Если да, то как? Каким образом клиент удостоверяет аутентичность сервера?
Поддерживается ли кэширование ответов? Если да, то как? Каким образом клиент понимает, что на данный запрос ответ ему уже давали, и можно использовать его, вместо скачивания полного тела ответа?
Может ли сервер сообщить клиенту, что данный endpoint перенесен на другой адрес?
Может ли клиент после обрыва соединения попросить сервер дослать только недостающую часть, или должен повторно выкачивать полный ответ?
Можно ли на одном IP адресе разместить несколько независимых серверов, каждый из которых реализует свой API и изолирован от других?

PD>Клиент либо уже работал с этим сервером, либо нет. Если нет — он первым делом запрашивает его АПИ. Возможно АПИ будет достаточно сложным или многоуровневым, так что детали здесь требуют уточнения. Но для большинства коммерческих сайтов он слишком сложным не будет. Например, сайт туроператора. Запросы могут быть по странам, датам, отелям, самолетам и т.д. Ничего в приницпе тут нового нет и не будет, а если что-то поменяется — будет новая версия АПИ при том. что старая поддерживается.


PD>Если клиент имеет АПИ, он строит на его основе запрос к серверу. Это может быть сделано даже автоматически, так как АПИ разных серверов хоть и различен, но в основе его лежит унифицированный формат, XML, так что пострение запроса , в общем, может делаться одним или почти одним и тем же способом.

Не очень понятно, каким образом можно автоматически построить запрос к сервису с неизвестной семантикой. Не вполне понятно, предполагается ли использовать произвольный XML, или всё-таки на его основе будет построен некоторое конкретное расширение (типа того же чрезмерно избыточного XML-RPC).

PD>Сервер, получив запрос на родном ему АПИ, исполняет этот запрос. Если при этом возникают ошибки, он изготавливает ответ с XML, содержащем описание ошибки. В противном случае он возвращает XML с ответом.


PD>Клиент, получив этот ответ, парсит этот XML с помощью DOM/XPath или иначе. Там не может быть ничего постороннего, так как клиенту известен АПИ, и , стало быть, известно, что сервер может вернуть. Для решения проблемы с версиями достаточно указать версию в запросе и в ответе — естетсвенно, тоже в виде тега XML. Если клиент все еще для АПИ 1.2, то он и сообщит об этом, посылая запрос, что будет означать для сервера, что и ответ надо вернуть в рамках 1.2, а не 1.3. Но в ответе можно еще и сообщить, что 1.3 существует. Клиент, получив такое, может инициировать свой апгрейд.

Как именно он сможет инициировать свой апгрейд? Каким образом он получит данные о том, где расположены байты этого апгрейда? Какой протокол он будет использовать для скачивания апдейта?

PD>Ну а дальше уже парение в облаках. Существует google2, который не изучает HTML страницы серверов (о других функциях я не говорю сейчас), а запрашивает у них их АПИ. Используя на google2 мощные аппаратурные средства, производится анализ этих АПИ и реализуется внешний интерфейс, по которому все желающие могут получить информацию о том, какие АПМ существуют, где они находятся, их версии и т.д. Эту информацию приложения (хоть web, хоть не web) могут запросить и использовать для определения, к кому надо обратиться и с каким запросом. Парение в космическом пространстве — google2 принимает запрос на естественном языке и формирует N вызовов АПИ разных серверов, которые и передаются клиенту, а ему остается эти вызовы только реализовать.


PD>Про HTML. Его никто не предлагает отменять. В XML ответе может слаться все, что угодно, в том числе и некий текст в некотором формате, который предназначен для его показа некоторым окном, именуемым окном броузера. XML ответ , содержащий TIFF файл, может быть использован для показа его в некотором графическом редакторе/вьюере. И т.д.


PD>Я прекрасно понимаю, что реальных шансов на широкомасшатбный переход к этой модели нет в ближайшем будущем. Я прекрасно вижу всякие стоимостные проблемы, проблемы безопасности и т.д. Но ведь мы архитектуру обсуждаем, не так ли. Поэтому прошу именно архитектуру и критиковать.

0. Поздравляю, вы изобрели SOAP 1.0. Такими темпами лет через десять ты изобретёшь SOAP 2.0.

Не очень понятно, что здесь ты называешь "архитектурой". Но давай попробуем раскритиковать твое решение, даже не учитывая существующей инфраструктуры. Предположим, что интернета нет, а сейчас — 1988 год. Чем отличается хорошее решение от плохого, при одинаковой функциональности? Очевидно, только стоимостью. Стоимостью в реализации, стоимостью в эксплуатации, стоимостью в доработке.

Вот какие тонкости влияют на эти стоимости:
1. Этот протокол очень плохо масштабируется. Невозможно экономить трафик, т.к. нет понятий кэширования, компрессии, и частичной передачи.
2. Нет способа сообщить клиенту, какие операции являются идемпотентными, а какие нет.
3. Тема апдейта клиентов не раскрыта.
4. Тема обхода брандмауэров не раскрыта.

Стоимость первоначальной реализации я не рассматриваю, т.к. считаю, что никаких апачей и библиотек в природе не существует. До них еще 10 лет, и к нашему протоколу (будь он успешным) напишут всё что надо. А вот эти проблемы будут анноить пользователей каждый день. Я уж не говорю про проблемы с развертыванием JAR и EXE и отсутствие единой схемы адресации. Я по-прежнему не могу отправить в письме ссылку на результат некоторого запроса, а вместо этого многословно объясняю "запусти pavel1.exe... В тулбаре нажми кнопку опен... Нету кнопки? А, тулбара нету? А, ну пойди в виндов-тулбарз-шоу тулбар... как его там... ага. Вот теперь опен... да.. и файл укажи... Что? Не открывает? Может, у тебя прокси стоит? Точно? Ну спроси у админа, как тебе через прокси выйти. Да, порт 52431. Или 432, я не помню точно. Ок. Как договоришься — перезвони мне, я объясню, куда дальше тыкать"
Я по-прежнему не могу использовать фунции твоего клиента в другом клиенте, потому что я не уверен, что мой пользователь скачал твоего клиента, и что они оба одинаковых версий. Помнишь, я упомянул про elephantsondemand.com? Он пользовался тем, что я нечаянно создал вместе с приложением c.com сервис, которым он может пользоваться. Да благодаря тому, что можно форму, расположенную на elephantsondemand.com сабмиттить на c.com, можно даже не учиться парсить результаты c.com. Можно сразу открыть нужный ответ в новом окне — народ сплошь и рядом делает это с google.com.

Итак, я свою критику навел. Теперь хотелось бы вспомнить средневекового монаха и спросить: а чем эта архитектура лучше, чем веб?
Где преимущества, которые можно наблюдать? Если мы вспомним, что сейчас 2008, а не 1988, и уже есть развитая инфраструктура, то для обоснования альтернативной реализации тех же концепций недостаточно сказать "ну... они не сильно хуже http... в узком классе случаев...". Надо как-то обосновать выдумывание лишних сущностей.

PD>Ну а в заключение пара слов о реальности такого.


PD>1. Skype. Бесспорно, десктопное приложение. В то же время очевидно, что это Интернет приложение. Вот что мне сейчас tcpview о нем показал


PD>Skype.exe:1040 TCP divsoft:60801 117.8.238.206:4020 ESTABLISHED

PD>Skype.exe:1040 TCP divsoft:60801 154.business-link-static.sovintel.spb.ru:60721 ESTABLISHED
PD>Skype.exe:1040 TCP divsoft:1609 83.167.103.156:13915 ESTABLISHED
PD>Skype.exe:1040 TCP divsoft:60801 divsoft:0 LISTENING
PD>Skype.exe:1040 TCP divsoft:60801 fat.omsk.ru:1212 ESTABLISHED
PD>Skype.exe:1040 TCP divsoft:60801 host-195-49-170-70.avantel.ru:50941 ESTABLISHED
PD>Чего ему на 154.business-link-static.sovintel.spb.ru или host-195-49-170-70.avantel.ru нужно — понятия не имею. Может, эти хосты и не связаны логически, то есть с каждым он работает независимо. Может, он комбирирует данные полученные от них. Не знаю. Но работает он именно по этой модели, хотя XML тут или что-то иное — не знаю.
Никакого XML там естественно нет. Скайп занимается двусторонним стримингом аудиоданных; веб-приложения такого пока не могут. Но я думаю, что это ненадолго.

Возьмем, к примеру, youtube.com. Как ты думаешь, мой дорогой "теоретик архитектуры", почему нет аналогичного сервиса видеообмена, построенного на десктопных Windows Media Player или Winamp? Почему youtube не стал писать настольного клиента для протокола flv, а сделал веб-приложение? Может, там сидят идиоты, не понимающие в архитектуре?
Нет, судя по успешности сервиса там сидят отнюдь не идиоты.

Почему Winamp для mp3-radio использует HTTP, а не проприетарный протокол поверх TCP/IP? Наверное, тоже писали идиоты, которые не понимают, как классно изобретать всё с нуля.

PD>2. Desktop Weather. Аналогично


PD>DesktopWeather.exe:1204 TCP divsoft:1684 i.imwx.com:http ESTABLISHED

PD>DesktopWeather.exe:1204 TCP divsoft:1685 desktopfw.weather.com:http ESTABLISHED
Ага. Вот тут у нас все в порядке — номальное http-приложение. Оформлено в виде standalone. Я не очень такие люблю, потому что C:\Program Files\, в отличие от Temporary Internet Files, не резиновый. А ты рисковый парень — поставил екзешник неизвестно от кого. Входишь в группу риска — те 6% аудитории, за счет которых кормятся троянщики.
Кстати, не подскажешь — он в скольки местах одновременно умеет погоду показывать?
Подскажи, сколько будет завтра в Новосибирске?
Вот тот же сервис, вид сбоку за один клик:http://www.weather.com/outlook/travel/businesstraveler/wxdetail/RSXX0077?from=36hr_topnav_business&amp;dayNum=1

PD>3. SQLYog для MySQL. Чисто десктопное приложение. Запросы к БД делает по 3306 и шлет их не знаю по какому протоколу, но назову его условно SQL протоколом (не придирайтесь!) Я как-то смотрел его пакеты в сниффере, кое-что понять можно, хотя он не текстовый. Так или иначе, по некоторому протоколу шлется запрос, в котором то ли SELECT-INSERT, то ли что-то иное, не важно. Об АПИ клиент с севером давно договорились, а не договорились бы заранее — пришлось бы запрашивать протокол.

И? Павел, ты же не думаешь, что кто-то выставит свой MySQL сервер наружу в интернет? Да, есть некоторый протокол; он обычно используется локально, на той же машине, либо в пределах датацентра. Прикладной протокол на основе него не особенно построишь — сразу приходится придумывать какой-то application server, к которому уже будут цепляться клиенты.

PD>Обратите внимание, что нигде в приведенных примерах 80 порт и HTTP не используется. Между тем Desktop Weather имеет вид, вполне похожий на вид web-приложений — гиперлинки, табы и т.д. Отрабатываются эти гиперлинки в пределах самого Desktop Weather, если они к нему относятся, а если нет — открывают окно броузера.

Щас прям. Как раз Desktop Weather использует самый что ни на есть обычный HTTP. Включи фиддер — и увидишь, к какому веб-сервису он ходит.

PD>4. Ну и последнее. То, чем я сейчас занят. Если в общем виде — некая система взаимодействующих серверов и клиентов с протоколом их взаимодействия. Увы, бинарным пока что. Вот мы и учим эту систему XML понимать, чтобы новые серверы/клиенты могли с прежней системой взаимодействовать. Никаким HTTP там и не пахнет. Подробностей не будет.

Сочувствую вашим заказчикам. В случае если сервера и клиенты расположены в интернете. Да даже если это интранет — если бы вы выбрали HTTP, то получили бы надежную масштабируемую систему. А так вы занимаетесь просиранием средств на самописанные протоколы, которые будут страдать от всего того, что взрослые дяди вылечили примерно в 1996.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Я понял!!!!
От: dmz Россия  
Дата: 03.04.08 10:42
Оценка:
M>Павел хочет, чтобы с веб-страницы можно было выполнять запросы по любому произвольному протоколу.

M>То есть сейчас общение веб-страница <-> сервер ограничено HTTP и общением поверх HTTP. Павел хочет, чтобы с веб страницы можно было бы делать все то же, что и из полноценного десктоп-приложения — открывать произвольные порты, писать в них и читать из них любым протоколм, определенным программистом, принимать и отсылать произвольные данные и т.п.


что-то не очень понятно, зачем при этом страница.
Re: Я понял!!!!
От: Pavel Dvorkin Россия  
Дата: 03.04.08 10:49
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Я наконец-то понял в чем дело


M>Павел хочет, чтобы с веб-страницы можно было выполнять запросы по любому произвольному протоколу.


M>То есть сейчас общение веб-страница <-> сервер ограничено HTTP и общением поверх HTTP. Павел хочет, чтобы с веб страницы можно было бы делать все то же, что и из полноценного десктоп-приложения — открывать произвольные порты, писать в них и читать из них любым протоколм, определенным программистом, принимать и отсылать произвольные данные и т.п.


Вообще-то не только это, но и это тоже.
With best regards
Pavel Dvorkin
Re[2]: Я понял!!!!
От: Mamut Швеция http://dmitriid.com
Дата: 03.04.08 10:53
Оценка:
M>>То есть сейчас общение веб-страница <-> сервер ограничено HTTP и общением поверх HTTP. Павел хочет, чтобы с веб страницы можно было бы делать все то же, что и из полноценного десктоп-приложения — открывать произвольные порты, писать в них и читать из них любым протоколм, определенным программистом, принимать и отсылать произвольные данные и т.п.

dmz>что-то не очень понятно, зачем при этом страница.


Вот я и говорю, тчо от десктоп приложения это уже не будет отличаться никак
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[3]: Я понял!!!!
От: dmz Россия  
Дата: 03.04.08 10:54
Оценка: +1
dmz>>что-то не очень понятно, зачем при этом страница.

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


Главное, что это и сейчас можно сделать. Только, видимо, не только никому не нужно, но и вредно.
Re[27]: предложите решение
От: Pavel Dvorkin Россия  
Дата: 03.04.08 10:58
Оценка:
Здравствуйте, Mamut, Вы писали:

Я обещал не отвечать здесь, но этот ответ не по существу темы.


M>В топку такое приложение. Советую взять ближайшую игру и нажать Alt-Tab. Оппаньки фокус потеряли и в игру больше никакой нажатие не передается


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

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


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

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