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

HB>Так оно так и есть. Просто приложения организованы по разному — одним для исполнения нужен Windows, другим JVM, третьим .NET, четвертым браузер.

Вот со всем согласен, кроме броузера. Почему — уже объяснил. Если коротко еще раз — приложение должно быть самоуправляемым, а не выполняться в контейнере, который с ним что хочет, то и делает.

HB>И еще, все никак не пойму, чем Вам так HTTP не нравится? Вполне нормальный протокол, который, кстати не ограничивается GET/POST (а POST, в свою очередь, подходит далеко не только для передачи содержимого формы).

Я вообще-то ничего против не имею. Кстати, я и писал об этом

PD>А зачем, собственно говоря, и почему именно POST ? По логике вещей форма должна бы во-первых, определить, нужно ли тут тревожить сервкер, и если да — послать ему некий запрос общего вида (например, в виде XML), в котором, может быть, значения введенных пользователем полей и не упоминались бы, получить от него ответ и в соответствии с ним модифицировать состояние клиентского приложения — от установки галочки в check до полного обновления содержимого.

Ну а XML, естественно, можно по HTTP посылать. Мне не HTTP не нравится, мне POST не нравится в нынешнем виде. Как это в ASP.NET или Tapestry сделано. А вообще-то я к протоколу равнодушен. В конце концов любой протокол поверх TCP/IP годится, лишь бы можно было надежно данные пересылать. ICQ не использует HTTP и живет себе, Skype — тоже. Если ICQ заставить пересылать свои пакеты по HTTP — думаю, и это удалось бы сделать.

А пока что я опять Ctrl-A, Ctrl-Ins сделал. Не отвечает сервер...

PD> Понадобились ему некие данные, своих нет, а есть некий web-сервис, что их дает. Приконнектились к нему и стали web-приложением. Без всякого броузера.

Вот браузер все это изменил

Как простой пример. Мне друг прислал фотки с их корпоратива, http://www.flickr.com/photos/tags/party/clusters/ (ссыдка взята наугад, это не мой друг, если что )

Используя эту ссылку я имею моментальный доступ к его фотоархиву. Ни одно дескоп приложение такое делать не умеют. Вернее одно умеет — браузер

Или та же викимапия. Павел предлагал заменить ссылку на стандартный XML-файл, который можно передавать между приложениям (за точность цитаты не ручаюсь ) Зачем, если уже есть стандартизированый формат URI

И очень большой класс приложений в эту схему ложится идеально или очень хорошо


M>>Кстати, формы вполне могут друг с другом общаться, а не запрашивать сервер на каждый чих. Это все зависит от от программиста

PD>Я не специались в web-программировании. Готов тебе поверить, хотя и не пойму , как они это делают, по крайней мере при одном окне броузера.

Клиентский яваскрипт

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

PD>Ну а XML, естественно, можно по HTTP посылать. Мне не HTTP не нравится, мне POST не нравится в нынешнем виде. Как это в ASP.NET или Tapestry сделано. А вообще-то я к протоколу равнодушен. В конце концов любой протокол поверх TCP/IP годится, лишь бы можно было надежно данные пересылать. ICQ не использует HTTP и живет себе, Skype — тоже. Если ICQ заставить пересылать свои пакеты по HTTP — думаю, и это удалось бы сделать.

Посмотрите GWT. Это пример того, как можно извернуться на тех же основах веб-приложений (протокол HTTP, языки HTML/CSS/JavaScript). Всё приложение работает на клиенте, общается с сервером периодическими запросами. Пишется на Java. Работает в браузере. Плагины для браузера не нужны.

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

M>Как простой пример. Мне друг прислал фотки с их корпоратива, http://www.flickr.com/photos/tags/party/clusters/ (ссыдка взята наугад, это не мой друг, если что )

Ну и что ? Я же не предложил отменить броузер. В броузере зпходим по линку. Если это статика с картинками — бога ради. Если линк показывает на web-приложение — оно запускается.
Из него тоже ссылки есть. Если они в пределах этого же web-приложения — отрабатываем, как я писал. Если наружу — запускаем браузер. Возможно, это к запуску другого web-приложения приведет.


M>Используя эту ссылку я имею моментальный доступ к его фотоархиву. Ни одно дескоп приложение такое делать не умеют. Вернее одно умеет — браузер

И бога ради. Только нет здесь web-приложения.

Насчет десктоп-приложений, что не умеют — могу тебе минут за 5 сделать, которое сумеет. Делаем MFC приложение, view на базе CHtmlView — и вперед

M>Или та же викимапия. Павел предлагал заменить ссылку на стандартный XML-файл, который можно передавать между приложениям (за точность цитаты не ручаюсь ) Зачем, если уже есть стандартизированый формат URI

Ну во-первых, там размер ИМХО ограничен. Но не это главное. Если угодно, пересылай в виде URI. Хоть в двоичной форме пересылай, мне все равно. Но это не посылка на сервер POST, а просто запрос к серверу и ответ от него. Не имеющий , может быть, никакого отношения к внешнему виду и содержанию окна приложения.

M>Клиентский яваскрипт

Хм. А при перезагрузке страницы он как там выживет ? У нас ведь есть форма А, из нее линк на форму B (любым способом, хоть GET, хоть результат редиректа после POST), и вот в броузере страница B. Как там js от страницы A выжил ?

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

PD>Хм. А при перезагрузке страницы он как там выживет ? У нас ведь есть форма А, из нее линк на форму B (любым способом, хоть GET, хоть результат редиректа после POST), и вот в броузере страница B. Как там js от страницы A выжил ?

Hint: форму можно отправить, не перегружая страницу.

M>>Как простой пример. Мне друг прислал фотки с их корпоратива, http://www.flickr.com/photos/tags/party/clusters/ (ссыдка взята наугад, это не мой друг, если что )

PD>Ну и что ? Я же не предложил отменить броузер. В броузере зпходим по линку. Если это статика с картинками — бога ради. Если линк показывает на web-приложение — оно запускается.
PD>Из него тоже ссылки есть. Если они в пределах этого же web-приложения — отрабатываем, как я писал. Если наружу — запускаем браузер. Возможно, это к запуску другого web-приложения приведет.

Для уже очень многого это не имеет смысла. Особенно ссылки на скачиваемые и устанавливаемые приложения.

Например, тот же фликер предоставляет веб-интерфейс для редактирования своих изображений (каталогизация, переименование, rotate/crop). Весь интерфейс — javascript с Ajax'ом. Смысла делать для этого отдельно приложение нет, поому что сущетвующее решение покрывает наверное 90% всех потребнстей пользователя. А учитывая что фотографии и так хранятся нелокально, то смысла гонять туда-сюда полновесные картинки нет.

И вот мы имеем продвинутое веб-приложение в админке и упрощеный интерфейс того эе приложения для пользователя


M>>Используя эту ссылку я имею моментальный доступ к его фотоархиву. Ни одно дескоп приложение такое делать не умеют. Вернее одно умеет — браузер

PD>И бога ради. Только нет здесь web-приложения.

PD>Насчет десктоп-приложений, что не умеют — могу тебе минут за 5 сделать, которое сумеет. Делаем MFC приложение, view на базе CHtmlView — и вперед

Переизобретаем браузер?


M>>Или та же викимапия. Павел предлагал заменить ссылку на стандартный XML-файл, который можно передавать между приложениям (за точность цитаты не ручаюсь ) Зачем, если уже есть стандартизированый формат URI

PD>Ну во-первых, там размер ИМХО ограничен. Но не это главное. Если угодно, пересылай в виде URI. Хоть в двоичной форме пересылай, мне все равно. Но это не посылка на сервер POST, а просто запрос к серверу и ответ от него. Не имеющий , может быть, никакого отношения к внешнему виду и содержанию окна приложения.


Абсолютно аналогично с десктоп-приложением. Просто случае с десктоп приложением логика и отображение ближе друг к другу находятся

M>>Клиентский яваскрипт

PD>Хм. А при перезагрузке страницы он как там выживет ? У нас ведь есть форма А, из нее линк на форму B (любым способом, хоть GET, хоть результат редиректа после POST), и вот в броузере страница B. Как там js от страницы A выжил ?

Зависит от кривизны рук программиста Нет нерешаемых поблем

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

PD>Увы, я не вижу иного варианта, кроме как исполнения web-приложения в своем собственном окне. Будет это окно процесса броузер или же отдельного процесса — не так уж важно. Важно лишь одно — оно должно быть логически отделено от броузера. Внутри себя оно должно быть приложением как приложением, с возможностью передавать ему данные (Copy/Paste, из файла и т.д.), а сообщаться с броузером должно только по своей инициативе. Броузер, в свою очередь, должен иметь возможность сообщаться с этим окном, но не распоряжаться в нем как ему вздумается. Например, он может переслать ему команду "перейди в точку с координатами широта= долгота =" (это в применении к EARTH). Но, вполне возможно, приложение ему ответит — не могу выполнить команду, так как нахожусь в состоянии, не допускающем выполнении такой команды. Как и положено любому приложению — например, VS не позволит вам открыть новый проект, если вы в состоянии отладки текущего проекта.

Технологии уже есть, осталось их только освоить. Советую немного ознакомиться с XBAP.

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

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

PD>Основная проблема, связанная с web-приложениями, ИМХО заключается в том, что их как таковых нет . На клиенте. Нет приложения, имеющего свой жизненный цикл, однажды стартующего и когда-то заканчивающегося. Есть набор форм, почти никак на клиенте не связанных друг с другом.

Ты ошибаешься, рассматривая в качестве приложения только ту часть, которая размещена на браузере. В прочем, ты не одинок... По существу, это самые обыкновенные многопользавтельские приложения, у которых интерфейс пользователя реализован с использованием HTML (CSS, XML, ASP, и весь прочий зверинец). Сервер же ты по-любому не выкинешь, правда? А на нём как раз приложения стартуют, завершаются и вообще — работают. Ну а если рассматривать только кусок, то можно до многого договориться.

Мой любимый пример в этом смысле — IBM/Rational ClearQuest. Есть и web-интерфейс пользователя, и обычный. Конструктор форм работает как для web-варианта, так и для десктопного. Это web-приложение или нет? Имеет смысл рассматривать будущее его web-интерфейса в отрыве от будущего самого CQ? Думаю, что нет. Интерфейс, если понадобится — прицепят ещё один. Хоть на АЦ-терминале. Но не говорить же тогда об "АЦ-приложениях"?

PD>Так что раньше или позже, я надеюсь, здравый смысл и здесь возобладает

Здравый смысл никуда и не девался. Просто не нужно подменять целое частью.

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

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

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

PD>Именно это и произошло с web-формами. Пока форма сама по себе и ее единственное назначение — отослать введенные пользователем данные на сервер — все работает безупречно. Как только пытаемся сделать что-то более сложное — возникают проблемы.
Можно показать, что это за мифические проблемы?

PD>Вот представьте себе — выведено некое броузерное окно, пользователь что-то там делает/набирает, нажимает Submit. Форма посылает эти данные серверу. А зачем, собственно говоря, и почему именно POST ? По логике вещей форма должна бы во-первых, определить, нужно ли тут тревожить сервкер, и если да — послать ему некий запрос общего вида (например, в виде XML), в котором, может быть, значения введенных пользователем полей и не упоминались бы, получить от него ответ и в соответствии с ним модифицировать состояние клиентского приложения — от установки галочки в check до полного обновления содержимого.
Совершенно верно, в современных веб приложениях всё так и работает.

PD>Да беда-то в том, что нет никакого клиентского приложения. Есть только форма. И общаться формы напрямую не могут, потому как они заменяют друг друга в окне броузера. Вот и приходится этим формам при отсутствии клиентского приложения начинать общаться через сервер. Со всеми вытекающими последствиями в виде серверных событий по изменению состояния select и т.п. А состояния клиентской части и серверной части, вообще говоря, не синхронизированы, так как хозяин этих клиентских форм — не клиентское приложение, а броузер, и как таковой, он может делать все, что пользователь захочет, в том числе и не имеющее никакого отношения к этому web-приложению. Уходить из него и возвращаться, и при этом не ставля его (серверную часть) даже в известность. Отсюда и все проблемы вроде пресловутой кнопки Back.
Павел, это не проблема веб-приложений. Это твоя личная проблема: ты не знаешь о том, что формы могут общаться напрямую, что заменять друг друга в окне необязательно, что браузер — друг, а не враг веб-приложения.

PD>А вот если бы нормальное клиентское приложенияе было бы, оно бы и взяло на себя управление этими формами, их "листание", передачу информации от одной формы другой и т.д. И, разумееется, клиентское приложение реализовало бы всю "тяжелую" часть программы, вроде обработки изображений, расчет 3D графики, форматировния текста и т.д.
Да, есть такой недостаток. "Тяжелую" часть функциональности в веб приложениях на клиента не возложишь.
Именно поэтому как правило веб-приложения работают со "сверхтяжелой" функциональностью, когда клиенту заведомо неэффективно было бы ее выполнять. К примеру, поиск наилучшего автомаршрута из Лиссабона во Владивосток твой компьютер будет делать значительно дольше, чем Google Maps.

PD>Ближе всего к этой идее java-апплеты подошли. Но — не пошли они. Почему — трудно сказать. ИМХО просто из-за неудачной реализации.
Нет. Не пошли они потому, что пытались быть "приложением внутри странички". У них не было возможности нормально взаимодействовать с браузером.

PD>Нынешний AJAX — это отчаянная попытка вернуться к здравому смыслу, к клиентскому приложению то есть. В принципе AJAX мог бы быть полноценным клиентским приложением, если предположить, что страница (в смысле URL) всегда одна, и она изменяет себя вплоть до полной неузнаваемости, запрашивая данные с сервера.
Да, таким приложением является викимапия.
PD>Это многое решает, но не все. Броузер все же остается, с его свободой выполнять действия, к клиентскому приложению не имеющие отношения.
Действия браузера должны иметь отношение. Вот когда я нажимал кнопку back на страничке с джава-апплетом — это была катастрофа. Попробуй back/forward с викимапией.

Дальнейшие фантазии, продиктованные непониманием сути вещей, я опускаю.

Для иллюстрации того, о чем я писал, предлагаю простую задачку. Я изложу свое решение (в варианте гипотетического клиента), а все желающие могут изложить свое — в рамках любых существующих технологий.

Есть сервер a.com. К нему можно формировать запрос следующего вида. Вводим название продукта, и он возвращает его цену, габариты, вес и адрес отправителя. Почтовыми проблемами сервер a.com не занимется, не его дело.

Есть сервер b.com. К нему можно формировать запрос следующего вида. Подаем на входе вес, габариты, адрес отправителя и адрес получателя. Он возвращает стоимость пересылки. Что именно пересылается — ему совершенно безразлично.

Пользователь хочет следующее. Вводится название продукта и куда его надо отправить. В ответ выдается суммарная стоимость (самого продукта и почтовые расходы).

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

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

Ваше решение ?

Категорическое требование — сервер a.com решительно не хочет ничего знать о почтовых делах и даже о существовании b.com, а b.com — не интересуется продуктами и не знает о наличии a.com.

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

S>Дальнейшие фантазии, продиктованные непониманием сути вещей, я опускаю.

Ввиду отсутствия ответов по существу, а наличия только голословных утверждений, ответ опускаю.

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

M>Например, тот же фликер предоставляет веб-интерфейс для редактирования своих изображений (каталогизация, переименование, rotate/crop). Весь интерфейс — javascript с Ajax'ом. Смысла делать для этого отдельно приложение нет, поому что сущетвующее решение покрывает наверное 90% всех потребнстей пользователя. А учитывая что фотографии и так хранятся нелокально, то смысла гонять туда-сюда полновесные картинки нет.

M>И вот мы имеем продвинутое веб-приложение в админке и упрощеный интерфейс того эе приложения для пользователя

Да, где-то граница должна проходить. В конце концов статический сайт с регистрационной формой вряд ли требует чего-либо, кроме броузера. И более сложные задачи, возможно , тоже. И AJAX иожет тут решить проблему. Но вот что-то действительно серьезное, с изощренной логикой и т.д — тут, я думаю, нынешний подход сильно буксует.


PD>>Насчет десктоп-приложений, что не умеют — могу тебе минут за 5 сделать, которое сумеет. Делаем MFC приложение, view на базе CHtmlView — и вперед

M> Переизобретаем браузер?

Нет. Используем его. CHtmlView — это просто view для окна, в котором IWebBrowser2 сидит. В конце концов броузер из двух частей состоит. Одна часть, сильно навороченная — это само броузерное приложение, со всеми опциями и возможностями, SSL и сертификатами и т.д. Другая — просто очень своеобразный контрол, в котором можно картинки показывать, некоторые строчки подсвечивать, курсор над ними форму руки принимает и т.д., а для описания этому контролу, где и как все изобразить, используется некий язык под названием HTML. Вот эту вторую часть и несложно вставить в свое приложение. Впрочем, и от первой части там кое-что будет — отрабатываться линки будут.


M>>>Или та же викимапия. Павел предлагал заменить ссылку на стандартный XML-файл, который можно передавать между приложениям (за точность цитаты не ручаюсь ) Зачем, если уже есть стандартизированый формат URI

PD>>Ну во-первых, там размер ИМХО ограничен. Но не это главное. Если угодно, пересылай в виде URI. Хоть в двоичной форме пересылай, мне все равно. Но это не посылка на сервер POST, а просто запрос к серверу и ответ от него. Не имеющий , может быть, никакого отношения к внешнему виду и содержанию окна приложения.


M>Абсолютно аналогично с десктоп-приложением. Просто случае с десктоп приложением логика и отображение ближе друг к другу находятся

Именно. Так и должно быть.

А вообще, что такое десктоп-приложение ? Вот, к примеру, SQLYog — хороший продукт для администрирования MySQL. Типичное десктопное приложение. Но для связи с БД использует адрес хоста и порт. Чем это в принципе отличается от GOOGLE EARTH ? Только тем, что SQLYog шлет в БД SELECT-INSERT по не знаю какому протоколу, а GOOGLE EARTH должен картинки запрашивать по HTTP ?

M>>>Клиентский яваскрипт

PD>>Хм. А при перезагрузке страницы он как там выживет ? У нас ведь есть форма А, из нее линк на форму B (любым способом, хоть GET, хоть результат редиректа после POST), и вот в броузере страница B. Как там js от страницы A выжил ?

M>Зависит от кривизны рук программиста Нет нерешаемых поблем

Ну может быть, я тут не в курсе.

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

PD>Категорическое требование — сервер a.com решительно не хочет ничего знать о почтовых делах и даже о существовании b.com, а b.com — не интересуется продуктами и не знает о наличии a.com.

Делаем простой-простой сервис c.com:

http://www.c.com/estimateDeliveryPrice.ashx?itemName={itemName}&deliverTo={deliveryAddress}

Пользователю возвращается:
1. Результат оценки стоимости с сервиса b.com
1a. Если сервис b.com не может посчитать стоимость доставки, то выдается cтатус 400 и cоответствующий текст
1b. Если сервис a.com не может найти нужный товар, то выдается статус 404 и соответствующий текст
1с. Если сервис a.com недоступен, то выдается статус 400 и соответствующий текст.

2. Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в параметрах URL. После нажатия submit форма банально отправляет браузер на URL, сформированный по введенным пользователем данным.

3. Надо полагать, что приложение этим не ограничится, потому что абстрактные вопросы типа "сколько стоит привезти слона в Пензу" занимают только настоящих ученых. Реальные люди запрашивают цену доставки как часть некоторого большего use-case, поэтому это приложение скорее всего будет содержать ссылку на Order now, где пользователь сможет подтвердить и оплатить заказ. Но это фантазии, т.к. в ТЗ ничего подобного озвучено не было.

4. Если никаких параметров в URL не задано, то возвращается только форма без результатов поиска.

В результате мы имеем возможность
1. Воспользоваться приложением c.com не инсталлируя ничего на клиентскую машину, а просто набрав в address bar "c" и нажав Сtrl+Enter.
2. Поставить закладку на конкретный результат и вернуться к ней позже, причем если условия изменились, ему автоматически будет показана новая цена.
3. Быстро получить набор результатов для разных товаров и одинаковых адресов, или, наоборот, для одного товара на разные адреса.

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

M>>И вот мы имеем продвинутое веб-приложение в админке и упрощеный интерфейс того эе приложения для пользователя

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

Пока непонятно, что такое "изощренная логика".
Упоминавшиеся (чудовищные!) XML файлы с локейшнами, которые должен парсить специально обученный клиент, сосут. А вот веб-приложения — рулят. Наш ответ "списку мест для посещения в Омске": маршрут моего вояжа июня 2007 года.

Ок, давайте попробуем сделать что-нибудь действительно изощренное. К примеру, поиск кратчайшего пути в графе охрененного размера. Найдем, как проехать из одного Голливуда в другой:
http://maps.google.com/maps?saddr=Hollywood,+FL&geocode=&dirflg=&daddr=Hollywood,+West+Hollywood,+CA&f=d&sll=26.040127,-80.16037&sspn=0.305385,0.501938&ie=UTF8&ll=36.456636,-100.019531&spn=34.719507,64.248047&z=4

Задачку растеризации векторного представления маршрута я даже не беру в расчет — это даже на курсовую не тянет, пусть и с субпиксельным сглаживанием. Совершенно непонятно, почему до сих пор никто не родил приличную реализацию SVG. Давайте хотя бы построение пути сделем локально, а?

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

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

PD>Ваше решение ?

Создаем сервис на сервере c.com (замечу, что твое решение тоже откуда-то надо распространять). Сервис -- простая форма, с полями для названия продукта и адреса получателя. При нажатии на кнопку Submit клиентское приложение (форма) через AJAX делает два последовательных запроса на a.com и b.com, выдает результат. Как вариант, вызывать сервисы a.com и b.com будет c.com (например, сервисы a.com и b.com могут не быть доступны публично, а только для "партнеров"), а форма будет делать один-единственный запрос к c.com.

PD>Ваше решение ?

PD>Категорическое требование — сервер a.com решительно не хочет ничего знать о почтовых делах и даже о существовании b.com, а b.com — не интересуется продуктами и не знает о наличии a.com.

expedia.com

Помимо собственной базы, тянет данные также из всяких GPS(global planning system). Поьзователь загел, заказал отель+трансфер+перелет, expedia отослала все данные, кому надо, составила маршрут, отдала пользователю билет+путевку

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

S>Откуда клиент взялся на машине пользователя?

Был установлен в качестве web-приложения в моем понимании этого слова. Кто именно его поставил — несущественно. Он вообще может быть универсальным.

PD>>Категорическое требование — сервер a.com решительно не хочет ничего знать о почтовых делах и даже о существовании b.com, а b.com — не интересуется продуктами и не знает о наличии a.com.

S>Делаем простой-простой сервис c.com:

Пожалуйста, подробное описание того, как работает этот сервис. Подробное! В терминах HTTP, HTML и т.д.


S>Пользователю возвращается:
S>1. Результат оценки стоимости с сервиса b.com

Нет, пока что еще рано. Сначала свяжись с a.com, чтобы узнать габариты и вес. Без этого b.com с тобой и разговаривать не будет.

S>1a. Если сервис b.com не может посчитать стоимость доставки, то выдается cтатус 400 и cоответствующий текст
S>1b. Если сервис a.com не может найти нужный товар, то выдается статус 404 и соответствующий текст

Если несложно, объясни, в каком порядке будут 1a и 1b выполняться. В нынешнем — невозможно, см. выше.
И еще — куда 1b свой 404 вернет ?


S>2. Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в параметрах URL. После нажатия submit форма банально отправляет браузер на URL, сформированный по введенным пользователем данным.

На какой именно URL ?

Все остальное skipped. Если действительно хочешь ответить — потрать минут 5 и опиши схему в деталях. Например

Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в URL web-сервиса c.com (я правильно понял ? — PD) . После нажатия submit форма банально отправляет браузер на этот URL, сформированный по введенным пользователем данным. Получив этот HTTP запрос, сервис c.com выполняет следующие действия ... И по порядку.

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

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

PD>>Ваше решение ?

WF>Создаем сервис на сервере c.com (замечу, что твое решение тоже откуда-то надо распространять).

+1. Принимается. Но не совсем. c.com должен постоянно функционировать, предназначение его, вообще-то, непонятно для пользователя.

>Сервис -- простая форма, с полями для названия продукта и адреса получателя. При нажатии на кнопку Submit клиентское приложение (форма) через AJAX делает два последовательных запроса на a.com и b.com, выдает результат.

Тоже принимается.

>Как вариант, вызывать сервисы a.com и b.com будет c.com (например, сервисы a.com и b.com могут не быть доступны публично, а только для "партнеров"), а форма будет делать один-единственный запрос к c.com.

Все принимается. Именно это я и предложил. Замечу, что c.com здесь попросту не нужен, если бы код на клиенте мог сам обратиться к a.com и b.com.

Я к чему этот пример привел ? Если действовать в рамках классического "при нажатии Submit форма отсылает свои данные на сервер" — то ничего не выйдет, так как тут два сервера. А вот если на клиенте имеется приложение с более или менее изощренной логикой, то задача становится банальной. Хоть к десятку серверов по очереди (а то и параллельно с ожиданием обращайся. Вообще, делай что хочешь, не ограничивая себя ничем. К примеру, обращаешься ты к a.com, а он тебе в ответ — скачай файл с ftp://a.com .Качаем его, анализируем и на основе этого анализа делаем что-то. Письмо можешь отправить прямо с клиента. И т.д. Я это, конечно, не как пример хорошего стиля привел, а просто , чтобы продемонстрировать возможности.

А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать.

PD>Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в URL web-сервиса c.com (я правильно понял ? — PD) . После нажатия submit форма банально отправляет браузер на этот URL, сформированный по введенным пользователем данным. Получив этот HTTP запрос, сервис c.com выполняет следующие действия ... И по порядку.

Сервер (а не клиент) отправляет запрос на a.com, b.com, ...., x.com в порядке, предусморенном логикой приложения, формирует ответ и предоставляет его в сформированном виде клиенту на c.com

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

S>Упоминавшиеся (чудовищные!) XML файлы с локейшнами, которые должен парсить специально обученный клиент, сосут.

Ты уж хоть самому себе не противоречь. Только что ты мне про web-сервисы писал, в задаче с a.com и b.com. А для них рекоменлованный протокол — SOAP. XML то есть. И парсит его web-service просто так. Обучен он этому, понимаешь ли.

И с чего это XML файл с двумя координатами будет чудовищным ? Скорее уж командная строка чудовищная, особенно когда там русские буквы в виде %EC%AD... Я такое как-то плохо в ASCII в уме перевожу. А если там не на русском, а на грузинском ?