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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Подробнее, пожалуйста. Сервер — каким именно образом он эти запросы делать будет ?
S>Ты меня удивляешь.
S>Так и будет делать. Например,
S>

S>var request = WebRequest.Create("http://a.com/handlerpath");
S>

Я тебя не удивляю. Скорее провоцирую . Потому что именно этого ответа я и хотел. Но не сам высказать его, а чтобы ты высказал. Потому что выскажи это я — скорее всего, выяснилось бы, что я опять ничего не понимаю.

PD>>Он умеет сам запросы от броузеров принимать (с помощью web-сервера), а вот web-клиентом он не является. Добавим в него функциональность web-клиента ?
S>А почему ты думаешь, что ее там нету? curl есть на любом линуксе, WebСlient есть на любой винде. Про джаву/.net я и не говорю.

Именно этот ответ я и хотел.

S>Или ты думал, что веб-клиент — это Интернет Эксплорер?

Нет

Все, все необходимые ответы от тебя получены. Теперь изложу твой ответ систематически. Это будет твоя версия правильного web-приложения. Если бы я сразу его сам изложил, ты бы обязательно сказал, что я что-то не так понимаю или вообще не понимаю. А теперь, когда ответы от тебя получены, изволь нижеследующее решение либо подписать, либо поправить и подписать.

Условия задачи не повторяю, они есть.

Решение (твое)

Для решения этой задачи мы создаем промежуточный web-сервис c.com, на котором функционирует специальный web-сервис. Пользователь из броузера делает запрос к c.com, передавая в запросе адрес назначения и имя продукта. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com. Получив от него форму, он заполняет в ней поле названия продукта и отсылает по протоколу HTTP новый запрос к a.com, передавая указанную форму. Сервер a.com принимает этот запрос и формирует ответ. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. После этого c.com создает web-клиента и делает запрос к серверу b.com. Получив от него форму, он заполняет в ней поля вес и габариты и отсылает по протоколу HTTP новый запрос к b.com, передавая указанную форму. Получив ответ, он извлекает из него стоимость пересылки, добавляет к стоимости продукта, полученной от a.com и отсылает пользователю форму с результатом.(Обработка ошибок пропущена)

Давай договоримся вот о чем. Если ты с чем-то не согласен — возьми этот текст и отредактируй. Не надо мне 400 и 404, не вдавайся в такие детали, а просто отредактируй то, что я написал. И не критикуй. Не согласен — исправь. И подпиши — за сим, я , Sinclair, утверждаю, что это и есть правильно организованное web-решение поставленной задачи.

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

M>Причем тут сервер а? expedia — это сервер с.

Да, если c — проходит.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не надо исходить из того, что принципы, положенные в основу современной модели, являются наилучшими. Надо и своей головой думать иногда.
Совершенно верно.
PD>Я не телепат и не специалист по шарадам.


PD>Тебе не надоело аргументы в ее пользу приводить ? Я же уже ответил — хорошее приложение, не спорю. Твои аргументы все в одну фразу укладываются — посмотри, какое оно хорошее, вот что оно еще умеет и вот что, смотри. Какое это отношение к делу имеет ? Что, если бы это было десктопным приложением, он бы трафик больший устраивало ?
PD>Трафик определяется тем, что посылают и что принимают, а не тем, является приложение десктопным или нет. Если ICQ сделать web-приложением — что, трафик для передачи SMS изменится ?
Скорее всего да.

PD>>>Ладно, хватит, не стоит продолжать. Бессмысленно. Твоя зашоренность просто удивляет.
S>>Павел, у меня никакой зашоренности нет. У меня хватает опыта работы и с настольными, и с классическими "сетевыми" приложениями, и с веб-приложениями, и с веб-сервисами, и с SOAP будь он неладен. А вот ты практически ничего не знаешь про веб приложения, и продолжаешь из принципа цепляться

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

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

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну разница все же есть. Пользователь должен запрос к c.com устраивать, назначения которого он не понимает и догадаться о его существовании, мб, не сможет.
Вот, Павел, в этом-то и состоит фундаментальное отличие веб приложений от обычных.
Ты почему-то обошел вопрос о том, откуда появился твой клиент на машине у пользователя. Ведь клиент не входит (в отличие от браузера) в поставку операционной системы.
Пользователь должен этого клиента где-то взять, установить, настроить, причем назначения этого клиента он точно так же не понимает и догадаться о его существовании не сможет.

Приложение по отслеживанию цены пользователь найдет благодаря connectedness интернета. Как я нашел expedia? В интернете. Набери в гугле "flights Moscow to Seattle", и ты увидишь, откуда пользователь догадывается о существовании Expedia, Travelocity, Orbitz и прочих.

Есть онлайн реклама, которая опять же позволяет мне просто кликнуть по баннеру и начать пользоваться приложением. Безо всяких download-install-try-fail-uninstall.


PD>Может. Только вот при этом ему придется отнюдь не серверными делами заниматься, и изображать из себя то web-client, то ftp-client, то еще что-нибудь. Он уже, по сути не сервер, а нечто общее будет.
Павел, ты наверное плохо себе представляешь, что такое сервер. Это и есть серверные дела — обслуживать клиента. К кому он при этом обращается за помощью — его дело. Он может вызывать другие сервисы, причем как HTTP, так и FTP, SMTP, и произвольные протоколы вообще. "Чистых" серверов, которые не являются ничьими клиентами, в природе не существует.

M>>И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда.
PD>Да, только функционал его резко возрастает и становится не серверным.
Определение "серверного функционала" в студию.

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

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

M>????????????????????????????????????????????????????????????????????????

M>Какой нафиг веб-, фтп- и прочая клиент?

M>У нас есть отображение (веб-страница)
M>У нас есть логика (сервер)

M>Среди прочих сервер может обращаться к другим серверам за информацией по различным протоколам: SOAP, XML-RPC, двоичным протоколам на основе ASN.1, прямым обменом сырыми двоичными данными и проч. Что его менее сервером не делает

Именно. Выполнить действия по обращению к другим серверам. Когда кто-то обращается к другому серверу — его называют клиентом.

S>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Ты уж хоть самому себе не противоречь. Только что ты мне про web-сервисы писал, в задаче с a.com и b.com. А для них рекоменлованный протокол — SOAP.
S>>Кем рекомендованный?

PD>Microsoft.

А кто они такие, что бы чего-то рекомендовать для вебсервисов?

>>SOAP — чудовищный отстой, придуманный по трагической ошибке.

PD>И XML, конечно, тоже. Ясно.

Реализации "официального" SOAP плохо совместимы между собой. Все. Гвоздь в голову.

PD>Ладно, хватит, не стоит продолжать. Бессмысленно. Твоя зашоренность просто удивляет.

Не очень понятны предлагаемые альтернативы, так что я понимаю Sincler-а. Решительно все, что всплывало в топике, отлично делается
сейчас на сушествующих технологиях.

Т.е единственная реальная проблема — это сложности с изготовлением кросс-браузерных AJAX-приложений, но очевидно что она никуда не денется,
пока существует Microsoft или все остальные.

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

S>Определение "серверного функционала" в студию.

Отличия сервера от клиента в студию.

M>>Среди прочих сервер может обращаться к другим серверам за информацией по различным протоколам: SOAP, XML-RPC, двоичным протоколам на основе ASN.1, прямым обменом сырыми двоичными данными и проч. Что его менее сервером не делает

PD>Именно. Выполнить действия по обращению к другим серверам. Когда кто-то обращается к другому серверу — его называют клиентом.

И это его делает менее сервером?

M>>Причем тут сервер а? expedia — это сервер с.

PD>Да, если c — проходит.

Тогда в чем проблема?

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

M>>>Причем тут сервер а? expedia — это сервер с.

PD>>Да, если c — проходит.

M>Тогда в чем проблема?

Это я потом расскажу. Хочу от Sinclair утвержденное решение получить.

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

S>На, смотри: http://maps.live.com/#JnE9eXAubWljcm9zb2Z0JTdlc3N0LjAlN2VwZy4xJmJiPTY1LjQwMzQ0NDc4ODMwNzglN2UxMTIuNSU3ZTQxLjExMjQ2ODc4OTE4MDklN2U1My4zNDk2MDkzNzU=

В Safari 3.1 (Win) ничего не открылось. M(icro)S(ucks) — отстой

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

M>И это его делает менее сервером?

Я все же хочу дождаться ответа от Sinclair, чтобы не распыляться. Извини, но я просто физически не успеваю дискутировать с вами обоими, да и не только с вами

Здравствуйте, Hobot Bobot, Вы писали:

HB>Павел, Вы извините, конечно, но, по-моему, у Вас какое-то странное представление о работе веб-серверов и протоколе HTTP. Средства для отправки HTTP-запросов давным-давно существуют в любой веб-платформе. Никакой "формы" для этого не надо. Никакой особенной "функциональности веб-клиента" тоже.

Спокойно, спокойно. Жду ответа от Sinclair с утвержденным решением.

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

PD>Для решения этой задачи мы создаем промежуточный web-сервис c.com, на котором функционирует специальный web-сервис. Пользователь из броузера делает запрос к c.com, передавая в запросе адрес назначения и имя продукта. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com.

Так.

PD>Получив от него форму, он заполняет в ней поле названия продукта и отсылает по протоколу HTTP новый запрос к a.com, передавая указанную форму.

Ниакую форму получать не надо. c.com сразу делает нужный запрос по обговоренному заранее протоколу. Если это SOAP, то протокол описывается WSDL.

PD>Сервер a.com принимает этот запрос и формирует ответ. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. После этого c.com создает web-клиента и делает запрос к серверу b.com.

Так.

PD>Получив от него форму, он заполняет в ней поля вес и габариты и отсылает по протоколу HTTP новый запрос к b.com, передавая указанную форму.

См. выше. Никакую форму получать не нужно.

PD>Получив ответ, он извлекает из него стоимость пересылки, добавляет к стоимости продукта, полученной от a.com и отсылает пользователю форму с результатом.(Обработка ошибок пропущена)

Так.

M>>И это его делает менее сервером?

PD>Я все же хочу дождаться ответа от Sinclair, чтобы не распыляться. Извини, но я просто физически не успеваю дискутировать с вами обоими, да и не только с вами

Без проблем В любом случае я же контраргумент приготовил

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

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

PD>>Для решения этой задачи мы создаем промежуточный web-сервис c.com, на котором функционирует специальный web-сервис. Пользователь из броузера делает запрос к c.com, передавая в запросе адрес назначения и имя продукта. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com.

WF>Так.

PD>>Получив от него форму, он заполняет в ней поле названия продукта и отсылает по протоколу HTTP новый запрос к a.com, передавая указанную форму.

WF>Ниакую форму получать не надо. c.com сразу делает нужный запрос по обговоренному заранее протоколу. Если это SOAP, то протокол описывается WSDL.

Извини, но на a.com нет никакого SOAP и WSDL. Это просто www-сервер. К нему можно было бы напрямую обратиться из броузера.

Впрочем, дело не в форме. Без формы — пусть без формы. Делается запрос к http://a.com/getproduct.html и... опиши дальше.

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

M>Без проблем В любом случае я же контраргумент приготовил

Безусловно. Я твой аргумент запомнил — это не делает его менее серверным, а сферовакуумный сервер не существует. Он мне не мешает

А вот ответа от Sinclair что-то нет. Вместо него WFRag ответил. Поправил меня насчет формы, с остальным согласен. Но я все же надеюсь утвержденное Sinclair решение получить

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

PD>Извини, но на a.com нет никакого SOAP и WSDL. Это просто www-сервер. К нему можно было бы напрямую обратиться из броузера.

PD>Впрочем, дело не в форме. Без формы — пусть без формы. Делается запрос к http://a.com/getproduct.html и... опиши дальше.

Не так. a.com предоставляет "машинный" (со строгим, заранее обговоренным интерфейсом) сервис getproduct. Вот мы его и вызываем.

Если "машинного" сервиса на a.com нет, то и воспользоваться им мы не можем (извращения типа разбора HTML не в счёт, это не нормальный вариант, впрочем, имеющий право на существование).

Пример реализации REST сервиса (для простоты понимания):

URL GET-запроса: http://a.com/getproduct?product=Сапоги+Кирзовые

Ответ:
HTTP/1.0 200 OK
Content-Type: application/xml

<product>
<price>100.0</price>
<weight>2.0</weight>
...
</product>

Далее, разбираем XML, делаем запрос к b.com, формируем итоговый ответ. Идея ясна?

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

WF>Не так. a.com предоставляет "машинный" (со строгим, заранее обговоренным интерфейсом) сервис getproduct. Вот мы его и вызываем.

Фиг тебе, а не обговоренный интерфейс. a.com живет сам по себе и прекрасно живет. И о том, что вы собираетесь его из какого-то c.com вызывать, понятия не имеет. Все, что о нем известно, если уж быть точным — это то, что он http://a.com. Даже насчет getproduct.html я напрасно предположил. Вот если зайти на

http://a.com

из броузера, то путешествую по сайту, я со временем доберусь до страницы getproduct.html, заполню там форму и получу ответ в броузере же — габариты, вес и цену.

С чего это авторы a.com должны были согласовывать свой интерфейс с еще не существующим c.com ? Много вас, таких, c.com найдется, на всех интерфейсов не напасешься!

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

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

M>>Без проблем В любом случае я же контраргумент приготовил

PD>Безусловно. Я твой аргумент запомнил — это не делает его менее серверным, а сферовакуумный сервер не существует. Он мне не мешает

Не, у меня другой контраргумент

http://friendfeed.com/dmitriid

Это feed c 5 сервисов, на которых я зарегистрирован. Там еще 28 сервисов можно добавить. Все сервисы ничего друг о друг не знают, а вот friendfeed — надо же! — мало того, что умеет вытягивать с них данные, так еще и представлять их в унифицированой форме.

Это то самое веб-приложение, приложение, которое работает с абсолютно разными, ничего друг о друге не знающими, сервисами


В целом описаное здесь

Автор: Pavel Dvorkin
Дата: 02.04.08

решение правильное (за исключением, конечно "создает веб-клиента" и "заполняет форму" ), о чем, собственно, мы все и говорим

Автор: Mamut
Дата: 02.04.08

:

Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер.