Re: EXE, JAR... - Философия программирования

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

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

Рассмотрим классическую схему HTTP. Делается GET запрос , посылается страница, в ней разные поля, делается submit, и эти поля посылаются на сервер, где их принимает в свои ласковые объятия CGI. Вот для чего изначально и был разработан HTTP. И пока все ограничивалось именно таким сценарием — он вполне разумен.

Можно ведь и для десктопного приложения аналогичную модель предложить. Создается форма (диалог), посылается на экран, пользователь заполняет поля и по кнопке OK делается "POST" — эти поля передаются собственно приложению, которое с ними что-то делает (например, в клиентскую БД записывает). Пока десктопное приложение такими формами и ограничивается, само приложение (т.е код помимо кода форм) почти и не нужно, разве что определять, в какой последовательности формы выводить и откуда их брать, остальное формы и сами сделают.

Но десктопное приложение — это не набор форм, в общем случае. И нажатие кнопки OK (Apply, Execute, пункт меню, кнопка тулбара) вовсе не обязательно приводит к снятию полей из формы и их пересылке куда-то. А приводят, вообще говоря, к самым разнообразным действиям, реализуемым невидимой частью десктопного приложения.

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

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

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

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

А вот если бы нормальное клиентское приложенияе было бы, оно бы и взяло на себя управление этими формами, их "листание", передачу информации от одной формы другой и т.д. И, разумееется, клиентское приложение реализовало бы всю "тяжелую" часть программы, вроде обработки изображений, расчет 3D графики, форматировния текста и т.д. В общем, было бы приложением в обычном смысле этого слова, с любыми возможностями. А сервер делал бы то, что ему положено делать — например, записывал бы посланные клиентским приложением данные в БД или посылал бы клиентскому приложению заготовку очередной формы. И т.д.

Ближе всего к этой идее java-апплеты подошли. Но — не пошли они. Почему — трудно сказать. ИМХО просто из-за неудачной реализации. Вспомните, что представлял собой запуск java-машины в Netscape 4.0, к примеру. Если уж появилось об этом сообщение — ждите секунд 20-30. Да и сейчас java реализована не то, чтобы уж очень эффективно. Получить java heap error при размере хипа 256 Мб при обработке одного слайда ppt-файла — это, вообще говоря, суметь надо.

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

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

В целом ситуация мне напоминает историю с Windows 9x. Windows 9x — это очень сильно модифицированная MS-DOS 1.0

. Понемногу, без заранее продуманного плана действий, в эту MS-DOS вводили каталоги на диске, графические средства, защищенный режим (DPMI), вытесняющий, а потом истинный параллелизм и т.д. В итоге монстровидность этой системы все росла и росла, внутренняя логичность и стройность падала, система становилась все более и более ненадежной. К счастью, Микрософт это довольно рано поняла и начала линию NT. Первые версии NT (3.1, 3.5) ничего, кроме критики не вызвали, и явно проигрывали Windows 95 и по удобству юзеровского интерфейса, и по простоте работы, и по требованиям к ресурсам . И даже Windows 4.0 во многом проигрывала Windows 98. Но вреям шло, о линии 9x можно уже, пожалуй, и позабыть, а имеем мы XP-Vista, которые можно критиковать, конечно, но нельзя не признать, что это достаточно логичные и осмысленные по своим концепциям операционные системы.

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

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

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

PD>Увы, я не вижу иного варианта, кроме как исполнения web-приложения в своем собственном окне. Будет это окно процесса броузер или же отдельного процесса — не так уж важно. Важно лишь одно — оно должно быть логически отделено от броузера.

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

Согласен. Вообщем то всё к этому и идёт, AJAX — первый шаг в этом направлении. По идее нужен стандарт на взаимодействие браузера с исполняемым в нём клиентским приложением, в котором будут чётко определяться возможности браузера в этом приложении (те про которые ты написал). Вырожденный случай — окно браузера без кнопок, кроме кнопки закрытия, должен стать базовым для большей части приложений. Кстати такое окно используют некоторые разработчики, открывая страницу приложения не напрямую в браузере, а в окне с OLE компонентом IE (там нету стандартных кнопок назад вперед и т.д.).

PD>Но десктопное приложение — это не набор форм, в общем случае. И нажатие кнопки OK (Apply, Execute, пункт меню, кнопка тулбара) вовсе не обязательно приводит к снятию полей из формы и их пересылке куда-то. А приводят, вообще говоря, к самым разнообразным действиям, реализуемым невидимой частью десктопного приложения.

Но веб-приложение — это не набор форм, в общем случае. И нажатие кнопки OK (Apply, Execute, пункт меню, кнопка тулбара) вовсе не обязательно приводит к снятию полей из формы и их пересылке куда-то. А приводят, вообще говоря, к самым разнообразным действиям, реализуемым невидимой частью веб-приложения.

Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

M>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая

Через сервер, однако. Вместо того, чтобы на клиенте это делать

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

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

F>Согласен. Вообщем то всё к этому и идёт, AJAX — первый шаг в этом направлении. По идее нужен стандарт на взаимодействие браузера с исполняемым в нём клиентским приложением, в котором будут чётко определяться возможности браузера в этом приложении (те про которые ты написал). Вырожденный случай — окно браузера без кнопок, кроме кнопки закрытия, должен стать базовым для большей части приложений. Кстати такое окно используют некоторые разработчики, открывая страницу приложения не напрямую в браузере, а в окне с OLE компонентом IE (там нету стандартных кнопок назад вперед и т.д.).

После того, как отправил свое сообщение, вдруг сообразил — а ведь есть у меня такое приложение. Называется Weather Channel Desktop. Предложил мне его поставить, кажется, Skype, я согласился и не жалею. Внешне — интерфейс в стиле web-приложений, гиперлинки, самодельные меню и т.д. Связь с каким-то сервером осуществляет, иначе где бы он брал данные для прогноза погоды. Рекламу умеренно гонит. Какие-то новости , в основном по США. В общем, вполне web-приложение.

Только броузер ему даром не нужен. Это DesktopWeather.exe, самый обычный процесс Windows. Посмотрел сейчас его импорт — классический, то есть это даже не .Net приложение. Installer, uninstaller — все как положено, unwise.exe. Для работы использует Adobe Flash Player, внутри себя. Контекстное меню, его собственное.

Вот так и надо делать.

M>>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая

PD>Через сервер, однако. Вместо того, чтобы на клиенте это делать

Тогда это будет обычное десктоп-приложение. В любом случае тезис о "ничем не связаных друг с другом формах" неверен

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

M>>>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая

PD>>Через сервер, однако. Вместо того, чтобы на клиенте это делать

M>Тогда это будет обычное десктоп-приложение. В любом случае тезис о "ничем не связаных друг с другом формах" неверен

Я тебя что-то никак не пойму. Есть формы в броузере, посылаемые с сервера. есть их ответ, посылаемый на сервер. Между собой формы не взаимодействуют непосредственно, только через сервер. И при этом мы имеем обычное десктопное приложение. Объясни.

И кстати, если уж цитируешь — цитируй точно. Где я сказал о "ничем не связаных друг с другом формах" ? Нет такого. Я вот что сказал

PD>Есть набор форм, почти никак на клиенте не связанных друг с другом.

Выделено мной. Общаться друг с другом на сервере эти формы могут, тут спорить не о чем.

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

PD>Только броузер ему даром не нужен. Это DesktopWeather.exe, самый обычный процесс Windows. Посмотрел сейчас его импорт — классический, то есть это даже не .Net приложение. Installer, uninstaller — все как положено, unwise.exe. Для работы использует Adobe Flash Player, внутри себя. Контекстное меню, его собственное.

PD>Вот так и надо делать.

Это уже война между различными платформами для отображения клиентской части приложения: браузер с его DOM и AJAX, апплеты обрабатывающие flash, java апплеты. Что станет со временем более востребовано разработчиками и развито в техническом плане, то и станет доминирующей технологией. В данный момент это обсуждаемые здесь web-приложения, ущербные в том или ином плане перед другими. Если в какой-то момент в технологии всё явственнее вылазит её ущербность, то либо происходит массовый отказ от технологии, либо "спрос рождает предложение" и технология развивается в соответствии с потребностями сообщества, что, мне кажется, происходит и будет происходить с браузерными web-приложениями. Сейчас следующий шаг должны сделать разработчики браузеров, предоставив программисту UI контроль над оканами браузера по типу обычного десктоп приложения. Вы скажете, "ведь это уже есть в других технологиях". Возможно, но по тем или иным причинам эти технологии не дотягивают до уровня "браузера с DOM и AJAX" (причем я не имею в виду в первую очередь функциональность технологии).

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

M>>>>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая

PD>>>Через сервер, однако. Вместо того, чтобы на клиенте это делать

M>>Тогда это будет обычное десктоп-приложение. В любом случае тезис о "ничем не связаных друг с другом формах" неверен

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

Если формы будут общаться друг с другом только на клиенте, то чем тогда веб-приложение будет отличаться от десктоп-приложения?

PD>И кстати, если уж цитируешь — цитируй точно. Где я сказал о "ничем не связаных друг с другом формах" ? Нет такого. Я вот что сказал

PD>>Есть набор форм, почти никак на клиенте не связанных друг с другом.

PD>Выделено мной. Общаться друг с другом на сервере эти формы могут, тут спорить не о чем.

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

M>Если формы будут общаться друг с другом только на клиенте, то чем тогда веб-приложение будет отличаться от десктоп-приложения?

Опять неточно цитируешь. Почему это только на клиенте ? Вполне возможно, что и через сервер тоже будут. Но не в нынешнем стиле. Не через HTTP POST. См. мой исходный постинг в этом треде.

Но, в общем, я тебя понял. Цитирую себя

PD>Не должно быть никаких специальных web-приложений. Должны быть просто приложения

http://www.rsdn.ru/Forum/Message.aspx?mid=2888866&only=1

Другое дело, что организованы они могут быть внутри по-разному. Одни абсолютно десктопные, другим нужен локальный сервер, третьим — сервер в Интернете, а четвертым, может быть, и несколько таких серверов одновременно. Скрестить, к примеру. Google Earth с Desktop Weather

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

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

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

F>С чем не согласен, так это с тем, что отличительной чертой приложения обязательно должен быть Installer, Uninstaller. Я вообще не согласен что к понятию "приложение" привязывается такие вещи как установка, деинсталляция, версия и т.д. Приложение — средство предоставления пользователю информации по запросу и не более того. Совершенно необязательно (хотя и возможно при желании) загонять приложение в общем случае в рамки десктопного приложения.

Нет, это я вовсе не утверждаю, я просто пример Desktop Weather привел, что у него они есть. Вообще говоря, они скорее всего не нужны, достаточно просто щелкнуть по линку из броузера, в результате чего запустится это самое приложение. Тем более что инсталлер для Windows — это одно, для Linux — другое.

А вот насчет версии — не согласен. Версия должна быть. Я уже об этом писал. Более того, должны быть доступны предыдущие версии. Мне совсем не улыбается мысль, что авторы программы могут что-то в ней в любой момент поменять, после чего она станет работать несколько не так, как прежняя версия, и кому жаловаться ? Они-то хотели как лучше, я понимаю, а если их "лучше" мне поперек горла ? А если у них расчетный сервис, и из-за небольшого улучшения алгоритма процесс теперь сходится к несколько иным значениям ? Мне что, потом в отчете писать — расчет произведен с помощью такого-то сервиса, который до мая месяца выдавал такие-то результаты, а с мая иные ?

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

PD>>Не должно быть никаких специальных web-приложений. Должны быть просто приложения

PD>Другое дело, что организованы они могут быть внутри по-разному. Одни абсолютно десктопные, другим нужен локальный сервер, третьим — сервер в Интернете, а четвертым, может быть, и несколько таких серверов одновременно. Скрестить, к примеру. Google Earth с Desktop Weather

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

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

PD>Но, в общем, я тебя понял. Цитирую себя

PD>>Не должно быть никаких специальных web-приложений. Должны быть просто приложения

PD>http://www.rsdn.ru/Forum/Message.aspx?mid=2888866&only=1

PD>Другое дело, что организованы они могут быть внутри по-разному. Одни абсолютно десктопные, другим нужен локальный сервер, третьим — сервер в Интернете, а четвертым, может быть, и несколько таких серверов одновременно. Скрестить, к примеру. Google Earth с Desktop Weather

+100

Просто в сообщениях, как кажется, сквозит этакая нелюбовь к веб-приложениям

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

Версия может быть, но она совсем необязательна. Если приложение настолько специфично, что имеет значение её конкретная реализация (как в случае который ты описал), значит поддержка различных её версий ложится уже на плечи компании приложение выпускающей. Например, захочет наша доблестная налоговая инспекция переделать десктопное приложение "Справка по форме 3НДФЛ" на веб приложение. Формат результирующего файла в каждой версии программы разный и может не прочитаться в другой версии. Значит, чтобы обеспечить версионность, нужно делать что-то наподобие такого:

http://nalog.ru/3ndfl/ — здесь хостится актуальная версия приложения
http://nalog.ru/3ndfl2006/ — здесь хостится версия приложения за 2006 год
http://nalog.ru/3ndfl2005/ — здесь хостится версия приложения за 2005 год
и т.д.

Это по типу того как авторы программ хранят на официальном сайте архив старых версий для тех пользователей, которые предпочитают "ретро".

Ну или просто добавлять новые функции приложения не трогая старые (зависит от того, что конкретно делает приложение).

То есть в конечном счёте отношение к версиям зависит от самого разработчика приложения. Хорошие разработчики будут по необходимости сохранять версионность.

Различие с десктопными приложениями — невозможность контроля этого дела конечным пользователем. Впрочем на то она и клиент — серверная технология чтобы возникала такая проблема.

Вообщем Столлману придется обламаться с его хотением "полностью контролировать приложения"

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

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

букв много, а смысл ускользает.
если эта цитата — смысл всего текста, то это глупость

напоминает анекдот: "жопа есть, а слова "жопа" — нету".

я лично писал веб-приложения с довольно таки "толстым" клиентом в виде эксплорера и нервущимися соединениями ещё пять лет назад.
gmail работает совершенно как веб-приложение.

по-моему, всё высосано из пальца.
тут люди этим профессионально занимаются и пишут эти самые веб-приложения

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

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

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

Настоящие хакеры должны сами себе писать приложения, и соответственно, полностью их контролировать

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

Разработчики браузеров должны быть поддержаны институтами по стандартизации как это было в случае HTML, XML, CSS.
Сейчас эти изменения делаются на основе решения "браузер в браузере" по типу Adobe Flash, Silverlight и т.п., то есть по сути дела на браузер ставится плагин, расширяющий его функциональность. В идеале надо чтобы эти возможности попали прямо в DOM браузера. Для этого нужно принятие открытого стандарта, поддержанного производителями браузеров и разработчиками.

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

M>+100

M>Просто в сообщениях, как кажется, сквозит этакая нелюбовь к веб-приложениям

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

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

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

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

Здравствуйте, 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-программировании. Готов тебе поверить, хотя и не пойму , как они это делают, по крайней мере при одном окне броузера.

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

Здравствуйте, 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 выжил ?

Зависит от кривизны рук программиста

Нет нерешаемых поблем

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

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

Неясность изложения обычно происходит от путаницы в мыслях.

Здравый смысл никуда и не девался.

Просто не нужно подменять целое частью.

Здравствуйте, 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 с викимапией.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

Есть сервер 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 — и вперед

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

Нет. Используем его. CHtmlView — это просто view для окна, в котором IWebBrowser2 сидит.

) Зачем, если уже есть стандартизированый формат 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. Быстро получить набор результатов для разных товаров и одинаковых адресов, или, наоборот, для одного товара на разные адреса.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, 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>Ну может быть, я тут не в курсе.
Ну так поизучай. А то ты начинаешь делать смешные заявления, не разбираясь в сути вопроса.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, 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 отослала все данные, кому надо, составила маршрут, отдала пользователю билет+путевку

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

Здравствуйте, 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 форма отсылает свои данные на сервер" — то ничего не выйдет, так как тут два сервера. А вот если на клиенте имеется приложение с более или менее изощренной логикой, то задача становится банальной. Хоть к десятку серверов по очереди (а то и параллельно с ожиданием

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

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

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

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

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

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

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

M>expedia.com

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

Нарушает мое требование выше — сервер a.com решительно не хочет ничего знать о почтовых делах.

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

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

Я даже не знаю, что ответить, потому что для меня, как JEE разработчика, это совершенно нормально.

Более того, я с легкостью могу представить вариант, когда a.com и b.com, например, платны для того, кто предоставляет сервис c.com (не для конечного пользователя!). Как вариант, a.com и b.com -- лишь частные реализации сервисов и однажды их надо будет заменить на другие.

И еще тут такое архитектурное соображение. Если клиент, работающий с a.com и с b.com разрабатывается независимо от них (а это, в принципе, следует из условия), то в любом случае нужна какая-то прокладка между ними и клиентским приложением, для обеспечения меньшей связности.

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

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

Стоп. А какая, собственно разница?

PD>Я к чему этот пример привел ? Если действовать в рамках классического "при нажатии Submit форма отсылает свои данные на сервер" — то ничего не выйдет, так как тут два сервера. А вот если на клиенте имеется приложение с более или менее изощренной логикой, то задача становится банальной. Хоть к десятку серверов по очереди (а то и параллельно с ожиданием

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

Стоп. Какая разница?

Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно

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

И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда.

Хых. http://feedburner.com/ как, по-вашему, работает? Или, скажем, http://kayak.com/? или http://friendfeed.com/? Да банальнейший http://blogs.yandex.ru/?

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>И с чего это XML файл с двумя координатами будет чудовищным ?
Ну почему же с двумя? Речь шла про "список адресов, которые мне надо посетить".
Вот я тебе отправил ссылку на даже более продвинутую штуку — там есть разноцветные флажки, примечания, предполагаемые фрагменты маршрута. Ну и понятно, что штука интерактивная — т.е. ты к примеру можешь получить инструкции по проезду к любому из мест.
PD> Скорее уж командная строка чудовищная, особенно когда там русские буквы в виде %EC%AD... Я такое как-то плохо в ASCII в уме перевожу. А если там не на русском, а на грузинском ?
А зачем тебе русские буквы, на грузинском, и переводить? Для сервиса проблем с переводом нету, а человек и XML читать не будет.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, пока что еще рано. Сначала свяжись с a.com, чтобы узнать габариты и вес. Без этого b.com с тобой и разговаривать не будет.
А, тебе надо детали реализации сервера? Ок.

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

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

PD>На какой именно URL ?
Я же указал в начале.

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

PD>Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в URL web-сервиса c.com (я правильно понял ? — PD)
Да.
PD> . После нажатия submit форма банально отправляет браузер на этот URL, сформированный по введенным пользователем данным.
Да.
PD>Получив этот HTTP запрос, сервис c.com выполняет следующие действия ... И по порядку.
1. Сервис на c.com соединяется по протоколу HTTP с сервисом a.com и пытается получить результат.
Предполагаем три возможных ситуации:
1a. Сервис a.com вернул 200 Ok, т.е. товар найден. Мы парсим его response и переходим на шаг 2.
1b. Сервис a.com вернул 404 Not Found, т.е. товар не найден. Мы вернем клиенту 404, сообщение "товар не найден" и покажем стандартную форму из п. 4.
1с. Сервис a.com вернул что-то еще либо нам не удалось с ним связаться. Вернем клиенту 400, сообщение "ничего не работает" и покажем стандартную форму из п. 4.
Пока что мы пренебрегаем обработкой 302, 303, 304, и 307.
2. Отправляем запрос скомбинированный из данных, полученных в 1a от a.com и введенного пользователем адреса, на сервис b.com
Рассматриваем два варианта:
2a. Сервис b.com вернул 200 Ok, т.е. подсчет стоимости удался. Переходим на шаг 3.
2b. Сервис b.com вернул что-то еще либо нам не удалось с ним связаться. Вернем клиенту 400, сообщение "товар найден по адресу XXX, но с оценкой доставки возникли проблемы" и покажем стандартную форму из п. 4.
3. Показываем результат работы: стоимость доставки.
4. Показываем форму с двумя инпутами, в которой подставлены те значения, которые были переданы в URL. Метод у формы — GET, action="".
Всё. Полчаса работы. Никаких упражнений с аяксами в данной задаче выполнять не нужно — это не улучшит поведение системы.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>>expedia.com

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

PD>Нарушает мое требование выше — сервер a.com решительно не хочет ничего знать о почтовых делах.

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

Схема работает так:

— клиент зашел на http://expedia.com/ (сервер с) и сказал:
хочу отель в нью-йорке, 05.05-10.05, прилетаю я из парижа

— expedia ломанулась в свою базу данных отелей (сервер а), и запомнила:
отель есть

— expedia ломанулась в систему типа Amadeus (сервер b) или Galileo (сервер x) или любую GPS (сервера y1, y2...yn) и запомнила:
самолет есть

— expedia вернулась к клиенту (сервер с) и сказала:
нате вам сформированное предложение с отелями с сервера а и самолетами с сервера b

Причем клиенту пофиг, что и с какого сервера пришло

Другой пример. Я заказал на Амазоне товар. Я его выбрал, заплатил, его мне доставили. В момент отправки Amazon мне сказал: мы отправили ваш ттовар с помощью DHL, номер вашего заказа: X, проверить статус товара можно на сайте http://dhl.com/status/X

Все произошло абсолютно без моего участия, на сервере с(Амазон), который сам связал товар (сервер а) с поставщиком (сервер b), при этом сервер b так и не узнал, чем я оплачивал, какие еще товары я заказывал и т.п.

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

Microsoft.

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

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

PD>>И с чего это XML файл с двумя координатами будет чудовищным ?
S>Ну почему же с двумя? Речь шла про "список адресов, которые мне надо посетить".

Понятно. С двумя не будет, а вот если маршрут содержит 15-20 точек — будет. Все ясно.

S>Вот я тебе отправил ссылку на даже более продвинутую штуку — там есть разноцветные флажки, примечания, предполагаемые фрагменты маршрута. Ну и понятно, что штука интерактивная — т.е. ты к примеру можешь получить инструкции по проезду к любому из мест.

И что ? Хорошая программа, ничего плохого не скажу. Но что тут особенного ? БД у них мощная, карты хорошие, серверов много. Вот и все

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

А меня как раз заказчик просит сейчас сохранение в XML сделать и добавить возможность там редактировать кое-что. Я ему теперь объясню, что это все отстой, ибо так сказал Sinclair.

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

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

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

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

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

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

S>1. Сервис на c.com соединяется по протоколу HTTP с сервисом a.com и пытается получить результат.

Так, минуту. Сервис на c.com, что, содержит в себе web-клиента ? Как иначе он запрос-то делать будет ? И где он для этого форму возьмет ? У него она, стало быть, есть.

S>Предполагаем три возможных ситуации:

<детали skiped,согласен>

S>2. Отправляем запрос скомбинированный из данных, полученных в 1a от a.com и введенного пользователем адреса, на сервис b.com

Так, еще один web-клиент на c.com, или же перенастроили предыдущий клиент. Из первого клиента взяли данные , новую форму соорудили , в нее данные занесли и submit ей устроили ?

S>Рассматриваем два варианта:

<детали skiped,согласен>

S>3. Показываем результат работы: стоимость доставки.

То есть теперь c.com вернул ответ клиенту в ответ на его запрос.

Я правильно все понял ? Ничего не извратил ?

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

PD>Microsoft.
Не надо слушать всё, что говорит Microsoft. Надо думать и своей головой иногда.
PD>И XML, конечно, тоже. Ясно.
Нет, в XML ничего особенно плохого нет. Впрочем, я и не ожидал, что ты угадаешь.

S>>Вот я тебе отправил ссылку на даже более продвинутую штуку — там есть разноцветные флажки, примечания, предполагаемые фрагменты маршрута. Ну и понятно, что штука интерактивная — т.е. ты к примеру можешь получить инструкции по проезду к любому из мест.

PD>И что ? Хорошая программа, ничего плохого не скажу. Но что тут особенного ? БД у них мощная, карты хорошие, серверов много. Вот и все

Только она работает без файлов в неизвестном науке формате (на всякий случай напомню, что кроссплатформенного способа определить по XML файлу имя и адрес приложения, которое его должно открывать, не существует), без инсталляции какого-либо софта на клиента и очень-очень эффективно в плане сетевого трафика.
Ее вряд ли можно было бы существенно улучшить путем перехода на инсталлируемого клиента (чего тебе почему-то очень сильно хочется).
Основное отличие Google Earth — поддержка 3d.
Увы, оказывается и это не проблема для современных веб-приложений. Хочешь представить себе окрестности штаб-квартиры микрософт?
На, смотри: http://maps.live.com/#JnE9eXAubWljcm9zb2Z0JTdlc3N0LjAlN2VwZy4xJmJiPTY1LjQwMzQ0NDc4ODMwNzglN2UxMTIuNSU3ZTQxLjExMjQ2ODc4OTE4MDklN2U1My4zNDk2MDkzNzU=
Bird's eye работает без клиента.

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

PD>А меня как раз заказчик просит сейчас сохранение в XML сделать и добавить возможность там редактировать кое-что. Я ему теперь объясню, что это все отстой, ибо так сказал Sinclair.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>>1. Сервис на c.com соединяется по протоколу HTTP с сервисом a.com и пытается получить результат.

PD>Так, минуту. Сервис на c.com, что, содержит в себе web-клиента ? Как иначе он запрос-то делать будет ? И где он для этого форму возьмет ? У него она, стало быть, есть.

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так, минуту. Сервис на c.com, что, содержит в себе web-клиента ? Как иначе он запрос-то делать будет ? И где он для этого форму возьмет ? У него она, стало быть, есть.
Спрашивали — отвечаем.
Никакой формы в сервисе нет. Есть HttpWebRequest. Мы получаем HttpWebResponse, и делаем второй HttpWebRequest.
Форма — чисто клиентский артефакт; браузер умеет с ее помощью делать некоторое убогое подмножество HTTP-запросов.
PD>Так, еще один web-клиент на c.com, или же перенастроили предыдущий клиент. Из первого клиента взяли данные , новую форму соорудили , в нее данные занесли и submit ей устроили ?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

M>Стоп. А какая, собственно разница?

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

PD>>Я к чему этот пример привел ? Если действовать в рамках классического "при нажатии Submit форма отсылает свои данные на сервер" — то ничего не выйдет, так как тут два сервера. А вот если на клиенте имеется приложение с более или менее изощренной логикой, то задача становится банальной. Хоть к десятку серверов по очереди (а то и параллельно с ожиданием

M>Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно

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

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

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

Да, только функционал его резко возрастает и становится не серверным.

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

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

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

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

PD>Подробнее, пожалуйста. Сервер — каким именно образом он эти запросы делать будет ? Он умеет сам запросы от броузеров принимать (с помощью web-сервера), а вот web-клиентом он не является. Добавим в него функциональность web-клиента ?

Десктоп приложение как работает? Это [отображение + логика] Так?
Как работает веб-приложение? Это [отображение + логика] Так? Веб-страница — это отображение. Сервер — это логика. Что тут непонятного?

|уровень отображения|уровень логики

веб-страница       
           ----запрос--->
                         сервер
                                  --- запрос другим серверам --->
                                  <-- ответ с других серверов ---
           <---ответ----

Каким образом сервер будет запросы делать? Да каким угодно, в зависимости от того, какой API для взаимодействия ему предоставляют другие сервера. У мня товарищ одно врема тупо парсил HTML одного турецкого банка для того, чтобы получить курс валют, чтобы показать на своем сайте (при этом посетитель сайта ни сном ни духом не знал, что список валют получен с какого-то другого сервера)

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

PD>>Microsoft.
S>Не надо слушать всё, что говорит Microsoft. Надо думать и своей головой иногда.

Не надо исходить из того, что принципы, положенные в основу современной модели, являются наилучшими. Надо и своей головой думать иногда.

PD>>И XML, конечно, тоже. Ясно.
S>Нет, в XML ничего особенно плохого нет. Впрочем, я и не ожидал, что ты угадаешь.

Я не телепат и не специалист по шарадам.

S>Только она работает без файлов в неизвестном науке формате (на всякий случай напомню, что кроссплатформенного способа определить по XML файлу имя и адрес приложения, которое его должно открывать, не существует), без инсталляции какого-либо софта на клиента и очень-очень эффективно в плане сетевого трафика.

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

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

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

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

M>>Стоп. А какая, собственно разница?

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

define: пользователь?

Я — пользователь. Я зашел на expedia.com. Мне абсолютно фиолетово, к скольки серверам будет устроен запрос, я в итоге получу готовый ответ.

M>>Стоп. Какая разница?

PD>Продумай всю эту схему в деталях

Ответил здесь

M>>Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно

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

????????????????????????????????????????????????????????????????????????

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

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

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

Сервер может и не запрашивать такие данные, если он самодостаточен. Но как минимум он будет обращаться к базе данных тоже по какому-то протоколу (здесь он видать становится веб-фтп-клиентом, ага)

В результате сервер получает/генерирует какие-то данные, которые отправляются в уровень отображения — на веб-страницу

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

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

PD>Да, только функционал его резко возрастает и становится не серверным.

??????????????????????????????????????????????

Можно эту фразу перевести на русский? Или определение работы сервера в студию. Мне сложно представить себе некий сферовакуумный сервер, который существует в отрыве от внешнего мира

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

PD>Нет. Используем его. CHtmlView — это просто view для окна, в котором IWebBrowser2 сидит.

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

Как человек который немного в теме, могу тебя заверить что "вставить вторую часть в своё приложение" — это вовсе не так просто как это кажется на первый взгляд. Куча ньюансов, куча подводных камней. К примеру, пользователь отключил в IE показ картинок — и — опа — а где красивые картинки в моём приложении подевались? Выкрутил настройки безопасности IE на максимум (даже не я выкрутил, а администратор сети, он молодец и паранойик) — и опа, приложению нашему стало плохо. CHtmlView это слишком тонкая прослойка, для реальных приложений которые хостят MS HTML он решает лишь малую часть проблем.

И кстати балланс сложности между MS HTML (как ты его называешь — IWebBrowser2) и собственно IE ты понимаешь неправильно — самое сложное как раз MS HTML, с HTML рендерером, поддержкой Pluggable protocols, секьюрити, интеграцией с Active Scripting и т.п. А собственно IE — это лишь UI для показа менюшек и хостинга MS HTML. Именно поэтому есть с дюжину "альтернативных" IE — всякие там Maxthon и т.п., которые хостят MS HTML самостоятельно.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

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

А чем так плох SOAP?

... << RSDN@Home 1.2.0 alpha rev. 786>>

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, 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>Да, только функционал его резко возрастает и становится не серверным.
Определение "серверного функционала" в студию.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, 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>Именно. Выполнить действия по обращению к другим серверам. Когда кто-то обращается к другому серверу — его называют клиентом.

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

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

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

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

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

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

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

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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, чтобы не распыляться. Извини, но я просто физически не успеваю дискутировать с вами обоими, да и не только с вами

Без проблем

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

Здравствуйте, 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 — надо же! — мало того, что умеет вытягивать с них данные, так еще и представлять их в унифицированой форме.

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

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

), о чем, собственно, мы все и говорим:

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

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

Такое словосочетание как API уже отменили?

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

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

Тогда о чем вообще речь? Ты и из своего мифического приложения из условий задачи не сможешь толком воспользоваться сервисом a.com, если единственный протокол, по которому публикуется сервис -- это HTML/JavaScript.

PD>http://a.com

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

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

Им не надо ни с кем согласовывать. Им надо просто опубликовать свой сервис под любым удобным им "машинным" интерфейсом (SOAP, REST, JSONRPC), коли они хотят, чтобы их сервис использовался другими сервисами/приложениями.

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

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

Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

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

HB>Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

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

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

M>Такое словосочетание как API уже отменили?

Пожалуйста, подробнее об АПИ в плане разработки a.com. Что за АПИ они должны были сделать и как он должен бы выглядеть ? Вот у RSDN есть разные линки, по которым я могу попасть на ту или иную страницу. Это и есть АПИ ?

Здравствуйте, Lloyd, Вы писали:
L>А чем так плох SOAP?
Тем, что практически полностью хоронит все преимущества HTTP.
В настоящий момент это — крайне неудобный RPC. Он создает массу проблем, и почти никаких не решает.
"Настоящий" веб-сервис — это REST, т.е. использование addressability, connectedness, и statelesness.

... << RSDN@Home 1.2.0 alpha rev. 677>>

HB>>Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

PD>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Я берусь. Только сформулируйте запрос.

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

PD>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Обычно все-таки есть какие-то сервисы, расчитанные на интеграцию с другими приложениями. Например, тот же Google Maps имеет некий API и способ подключения к существующему приложению.

PD>>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

dmz>Я берусь. Только сформулируйте запрос.
В смысле, вопрос.

PD>>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

WF>Обычно все-таки есть какие-то сервисы, расчитанные на интеграцию с другими приложениями. Например, тот же Google Maps имеет некий API и способ подключения к существующему приложению.

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

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

WF>Тогда о чем вообще речь? Ты и из своего мифического приложения из условий задачи не сможешь толком воспользоваться сервисом a.com, если единственный протокол, по которому публикуется сервис -- это HTML/JavaScript.

Не хотел я открываться, да уж ладно.

А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?

Читай мое решение еще раз

http://www.rsdn.ru/forum/message/2899518.1.aspx

WF>Им не надо ни с кем согласовывать. Им надо просто опубликовать свой сервис под любым удобным им "машинным" интерфейсом (SOAP, REST, JSONRPC), коли они хотят, чтобы их сервис использовался другими сервисами/приложениями.

OK, принимается. Это уже ближе к делу. В таком случае, поправь мое решение (поскольку Sinclair что-то молчит) и выдай от своего имени. Я не буду ничего говорить, пока не увижу утвержденного решения. Иначе дискуссия будет бесконечной.

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

PD>Для решения этой задачи мы создаем промежуточный web-сервис c.com, на котором функционирует специальный web-сервис.
Мы создаем промежуточное веб-приложение.
Веб-приложение состоит из серверной части (код на стороне HTTP сервера), и клиентской части — некоего HTML/CSS/Javascript.
В нашем случае хватает банального HTML+CSS, JavaScript не нужен.

PD>Пользователь из броузера делает запрос к c.com, передавая в запросе адрес назначения и имя продукта.
Ну, давай подробнее.
0. Пользователь из браузера делает запрос к сайту c.com:
http://www.c.com/
1. Сервер в ответ отдает ему страницу, которая рассказывает о том, куда он попал, и всё такое прочее, что выходит из отдела маркетинга. Существенным является то, что с этой страницы есть ссылка на приложение. В нашем случае точкой входа в приложение является вот такой URL:
http://www.c.com/estimateDeliveryPrice.aspx
2. Теперь сервер отдает клиентскую часть приложения. Это банальная HTML форма. Принципиальное устройство формы таково:

<form>
 <label for="itemName">Введите название товара:</label><br>
 <input id="itemName" name="itemName" type=text size=50><br>
 <label for="deliveryAddress">Введите название товара:</label><br>
 <textarea id=deliveryAddress name=deliveryAddress rows=5 cols=80>
 </textarea>
 <input type=submit value="поехали">
</form>

3. Получив эту форму, агент(браузер) показывает ее пользователю. Пользователь заполняет данные и нажимает Submit.
4. В соответствии со спецификацией HTML и HTTP, браузер выполняет переход на адрес
http://www.c.com/estimateDeliveryPrice.aspx?itemName=слон&deliveryAddress=Омск
Вот теперь
5. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com.
Этот момент не вполне понятен. Поскольку ты ничего не сказал про то, как устроен сервер a.com, мне трудно делать какие-либо предположения о том, как именно будет сформирован запрос. Получать форму с a.com большого смысла нет — если поменяется обработчик формы, то скорее всего изменится и сама форма.
Поэтому скорее всего серверная часть приложения c.com отправит HTTP POST-запрос на известный ей адрес где-то на сервере a.com.
6. Сервер a.com принимает этот запрос и формирует ответ.
7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com
8. После этого c.com отсылает по протоколу HTTP новый запрос к b.com, передавая данные, полученные от пользователя и a.com
9. Получив ответ, он извлекает из него стоимость пересылки, добавляет к стоимости продукта, полученной от a.com и отсылает пользователю форму с результатом.(Обработка ошибок пропущена)
Вот, это и есть правильное решение поставленной задачи. С точностью до обработки ошибок, кэширования, и деталей протоколов взаимодействия с a.com и b.com.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Отличия сервера от клиента в студию.
Клиент — активная сторона взаимодействия, сервер — пассивная.
Термины "клиент" и "сервер" могут применяться только в контексте конкретного диалога.
Например, когда я отправляю почту по SMTP, мой outgoing MTA — сервер, а outlook — клиент.
Когда тот же самый MTA отправляет почту на responsible MTA адресата, он является клиентом.
Когда responsible MTA возвращает моему MTA delivery status notification, он становится клиентом, а мой MTA — опять сервером.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

PD>Не хотел я открываться, да уж ладно.

PD>А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?

Вот и отлично. Пусть это какие-то сервисы, с известными протоколами.

PD>OK, принимается. Это уже ближе к делу. В таком случае, поправь мое решение (поскольку Sinclair что-то молчит) и выдай от своего имени. Я не буду ничего говорить, пока не увижу утвержденного решения. Иначе дискуссия будет бесконечной.

Примерно так:

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

Я не пойму, в чем подвох-то? o_0

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

HB>>Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

PD>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Какой ответ?
Я вообще не могу понять в чем вы видите разницу между обращением к сервисам a.com и b.com из клиентской программы или из кода, выполняющегося на третьем сервере. Ну нет этой разницы — независимо от того, какой протокол поддерживают a.com и b.com.

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

PD>А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?
Это как раз совершенно неважно, чего именно они серверы.
Серверы — значит умеют отвечать по некоторому известному протоколу.
Если не умеют — значит они не существуют в природе, т.е. это не серверы.

... << RSDN@Home 1.2.0 alpha rev. 677>>

M>>Такое словосочетание как API уже отменили?

PD>Пожалуйста, подробнее об АПИ в плане разработки a.com. Что за АПИ они должны были сделать и как он должен бы выглядеть ? Вот у RSDN есть разные линки, по которым я могу попасть на ту или иную страницу. Это и есть АПИ ?

ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ

RSDN@Home умеет вытягивать данные с RSDN.ru? Умеет. Почему сервер некоег сервиса не может вытягивать данные с RSDN.ru абсолютно таким же образом?

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>>Пользователь из броузера делает запрос к c.com, передавая в запросе адрес назначения и имя продукта.
S>Ну, давай подробнее.
S>0. Пользователь из браузера делает запрос к сайту c.com:
S>http://www.c.com/

Вот это ясно.

S>1. Сервер в ответ отдает ему страницу, которая рассказывает о том, куда он попал, и всё такое прочее, что выходит из отдела маркетинга. Существенным является то, что с этой страницы есть ссылка на приложение.

Я правильно понял, что предыдущее решение, когда делается запрос от клиента к c.com и все остальное вплоть до получения окончательного ответа, происходит без участия клиента ? Вроде так было. Или нет ? Как я понял — уже нет. Два этапа — просто запрос к c.com, получение страницы с "о том, куда он попал, и всё такое прочее" и ссылкой на приложение ? Ладно.

>В нашем случае точкой входа в приложение является вот такой URL:
S>http://www.c.com/estimateDeliveryPrice.aspx

Допустим.

S>2. Теперь сервер отдает клиентскую часть приложения. Это банальная HTML форма. Принципиальное устройство формы таково:

<skipped>

S>3. Получив эту форму, агент(браузер) показывает ее пользователю. Пользователь заполняет данные и нажимает Submit.
S>4. В соответствии со спецификацией HTML и HTTP, браузер выполняет переход на адрес
S>http://www.c.com/estimateDeliveryPrice.aspx?itemName=слон&deliveryAddress=Омск

Жду слона с нетерпением. Розовый чтоб был!

S>Вот теперь
S>5. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com.
S>Этот момент не вполне понятен. Поскольку ты ничего не сказал про то, как устроен сервер a.com, мне трудно делать какие-либо предположения о том, как именно будет сформирован запрос. Получать форму с a.com большого смысла нет — если поменяется обработчик формы, то скорее всего изменится и сама форма.

Прекрасно. Я действительно ничего не сказал. АПИ, который тут требуют другие, не определен. А посему куда именно твой web-клиент обратится, я тоже не знаю. Но и определять я его не буду — не мое же решение, а твое. Определи как хочешь и расскажи, как. Назначаю тебя на некоторое время разработчиком a.com. Только имей в виду, что c.com будет делаться через 5 лет, а может, и вообще не будет. Ты о нем ничего не знаешь.

S>Поэтому скорее всего серверная часть приложения c.com отправит HTTP POST-запрос на известный ей адрес где-то на сервере a.com.

Пусть так.

S>6. Сервер a.com принимает этот запрос и формирует ответ.

Подробнее, пожалуйста ? Шлет в ответ страницу ?

S>7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com

Во-во. Не уходи от этого ответа. Я ведь тебя 5 лет назад назначал разработчиком a.com, а сейчас я разрабатываю c.com, так что будь добр ответь мне, как там все это вытащить. Кстати, твоя страница еще картинку с этим продуктом шлет и прочее. Мне это без надобности, расскажи, как отфильтровать.

S>8. После этого c.com отсылает по протоколу HTTP новый запрос к b.com, передавая данные, полученные от пользователя и a.com

Ну это ясно.

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

Здесь тоже ясно. Кроме того, как вытащить из страницы от b.com стоимость пересылки. Но это та же проблема. Правда, разработчиком b.com ты не был, так что даже рассказать ничего не можешь...

Просьба — еще одну итерацию. Только опять полный текст. Не надо формы приводить, несущественно это. Словами опиши. Но полное решение. И подпишись

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

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

PD>>Не хотел я открываться, да уж ладно.

PD>>А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?

WF>Вот и отлично. Пусть это какие-то сервисы, с известными протоколами.

Теплее

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

Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?

А подвоха нет никакого.

Ответов сегодня от меня больше не будет. До завтра!

Павел, а можно такое же полное решение для аналогичного клиентского приложения? С подписью и печатью.

PD>Прекрасно. Я действительно ничего не сказал. АПИ, который тут требуют другие, не определен. А посему куда именно твой web-клиент обратится, я тоже не знаю. Но и определять я его не буду — не мое же решение, а твое. Определи как хочешь и расскажи, как. Назначаю тебя на некоторое время разработчиком a.com. Только имей в виду, что c.com будет делаться через 5 лет, а может, и вообще не будет. Ты о нем ничего не знаешь.

И как это веб до сих работает, ума не приложу

Google APIs
PayPal API
Amazon APIs
Amadeus API (раз уж мы про туризм говорили)

Сервис c.com создается не в вакууме, и сервисы a.com и b.com тоже существуют не в вакууме. Самый крайний случай — это выдирание и парсинг HTML'я (web-scraping), но это действительно самый крайний случай.

А так люди веб-сервисы и микроформаты исключительно для десктоп-приложений выдумали, ага

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

PD>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?

Это зависит от сервисов. Google APIs вполне себе поверх REST живут. Предлагаю домашнее задание — изучить, что такое SOAP, и как с помощью него делаются запросы (hint: c помощью GET/POST)

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

PD>Ответов сегодня от меня больше не будет. До завтра!

Я хоть тоже наконец-то за работу возьмусь

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

L>>А чем так плох SOAP?
S>Тем, что практически полностью хоронит все преимущества HTTP.
S>В настоящий момент это — крайне неудобный RPC. Он создает массу проблем, и почти никаких не решает.
S>"Настоящий" веб-сервис — это REST, т.е. использование addressability, connectedness, и statelesness.

А как REST решает поддержку транзакционности? Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?

P.S. а что подразумевается под connectedness?

... << RSDN@Home 1.2.0 alpha rev. 693>>

C>А как REST решает поддержку транзакционности? Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?

Никак не решает. А что — SOAP как-то решает?

dmz>Никак не решает. А что — SOAP как-то решает?

Может, десктоп-приложения как-то унифицированно решают?

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

C>>А как REST решает поддержку транзакционности? Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?

dmz>Никак не решает. А что — SOAP как-то решает?

Например:
http://en.wikipedia.org/wiki/WS-Transaction
http://en.wikipedia.org/wiki/WS-Security
http://msdn2.microsoft.com/en-us/webservices/aa740689.aspx

Кроме того, SOAP не привязано к HTTP/HTTPS в отличии от REST. Главный смысл SOAP и Web Services в стандартизации общения между сервисами + наличие инструментов, которые позволяют автоматизировать часть работы.
Конечно всегда можно создать REST решение, превосходящее во всех отношениях SOAP и "WS-*", вопрос лишь во времени разработки и удобства использования.

... << RSDN@Home 1.2.0 alpha rev. 693>>

M>(hint: c помощью GET/POST)
Имел в виду с их помощью в том числе. HTTP ничем не отличется от других протоколов взаимодействия

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>Подробнее, пожалуйста. Сервер — каким именно образом он эти запросы делать будет ? Он умеет сам запросы от броузеров принимать (с помощью web-сервера), а вот web-клиентом он не является.

Мда... На этом сообщении, пожалуй, остановлюсь. А то ведь собрался всю тему читать

... << RSDN@Home 1.2.0 alpha 4 rev. 1062>>

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

PD>Пусть так.

S>>6. Сервер a.com принимает этот запрос и формирует ответ.

PD>Подробнее, пожалуйста ? Шлет в ответ страницу ?
Как правило — да.
S>>7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com

PD>Во-во. Не уходи от этого ответа. Я ведь тебя 5 лет назад назначал разработчиком a.com, а сейчас я разрабатываю c.com, так что будь добр ответь мне, как там все это вытащить.
Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ. Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.

PD>Кстати, твоя страница еще картинку с этим продуктом шлет и прочее. Мне это без надобности, расскажи, как отфильтровать.
Из упоминания картинки я делаю вывод, что HTML ты тоже не знаешь. Дело в том, что "картинку" страница не отсылает. Картинка в ней присутстует в виде ссылки. Веб браузер ее автоматически вытаскивает, а мой сервис c.com этого делать не будет. Поэтому никакого "отфильтровать" не надо.

S>>8. После этого c.com отсылает по протоколу HTTP новый запрос к b.com, передавая данные, полученные от пользователя и a.com

PD>Ну это ясно.

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

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

Оба варианта приведены для случая, когда разработчики a и b не осознавали популярности своих услуг, и делали исключительно человеко-ориентированные приложения. В реальной жизни у обоих сервисов есть один или несколько HTTP-based API.
Если они разработаны в конце девяностых, то это будет банальный HTTP POST, где и запрос и ответ представлены в виде пар ключ=значение. Такой протокол поддерживает большинство платежных систем — по историческим причинам.
Если разрабатывались в 2000-2003, то скорее всего будет применено что-то типа XML-RPC. В 2003-2006 был в моде SOAP. В 2007-2008 начинается восход архитектуры REST и микроформатов; а также всякая экзотика вроде JavaScript API. Эти API обычно документированы, что позволяет мне легко интегрировать их услуги в свое приложение.

PD>Просьба — еще одну итерацию. Только опять полный текст. Не надо формы приводить, несущественно это. Словами опиши. Но полное решение. И подпишись

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

M>>Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно
PD>Может. Только вот при этом ему придется отнюдь не серверными делами заниматься, и изображать из себя то web-client, то ftp-client, то еще что-нибудь. Он уже, по сути не сервер, а нечто общее будет.

И правильно. Поскольку это есть узел распределённой информационной системы. Что он делает, по каким протоколам с кем-то ещё связывается — вопрос очень сильно отдельный. "Сервер", это же не награда за доблесть, а просто роль (как, кстати, это правильно отметил Sinclair) в определённых взаимодействиях. Скажу больше, в рамках одной транзакции узлы А и Б могут резко поменяться ролями и не один раз. Соответственно, на одном физическом компьютере (или кластере) могут исполняться программы, выполняющие как роль серверов (предоставление сервисов), так и роль клиентов (запрос данных, использование других сервисов). Дальше банальная формальная логика: некий компьютер может выполнять преимущественно серверные функции, и потому его можно обобщённо назвать "сервером". Но из того, что его назвали "сервером" ещё не следует, что этот компьютер выполняет только серверные функции.

PD>>>А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать.
M>>И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда.
PD>Да, только функционал его резко возрастает и становится не серверным.

И славно! Как минимум, пользователь избавлен от необходимости апдейтить своё приложение, если a.com и b.com надумали поменять API, добавить/убрать услуги и т.п. Всем этим централизованно занимается обслуга c.com.

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

PD>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?

c.com — есть веб-приложение с точки зрения конечного пользователя. Потому что оно предлагает ему веб-интерфейс и расположено в веб, а не на его десктопе. И единственным условием его использования для конечного пользователя является наличие у него совместимого браузера. Все. Это и определяет статус "веб-приложение" (для конечного пользователя)

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

Ну и как уже сказано -если a.com и b.com — это именно сервисы, а не конечные приложения, то они должны предоставлять какое-то АПИ для использования их функционала другим ПО (для веб-сервисов это логичнее всего что-то поверх http/https, но в принципе — не обязательно). Если такого функционала нет — то это просто клиентские приложения, но не сервисы. И строить приложения поверх них — плохая идея. Это все равно что делать, ну например, десктоп приложение, которое бы из ICQ брало приходящий текст и отображало его в Acrobat Reader. И потом удивляться, что это, блин, неудобно!

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

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

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

В качестве критики воспользуюсь благородным древним слогом: "Галимый отстой! Это же 2-уровневая система! Да ещё и с толстым клиентом! А если сервер поменяется? Что? Всех клиентов обновлять? Щаззз, разбежался! Маздай!!! Эн-тайер рулит форевер!"

По существу, от 2-уровневых приложений (тем паче, с толстыми клиентами) стали отказываться как раз из-за проблем с деплойментом обновлений. Тонкие клиенты на базе JS и иже с ними начисто лишены этих заморочек (Ctrl-F5 не считается). Другое дело, что изобразительные возможности HTML — ну да, это печально, конечно.

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

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

Нужно оценить изменчивость требований и колебания интерфейсов a.com и b.com. Если они меняются часто, то есть вероятность, что клиентские приложения очень быстро окажутся неработоспособными, либо нужно сразу вводить возможность автообновления приложения.

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

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

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

L>>>А чем так плох SOAP?
S>>Тем, что практически полностью хоронит все преимущества HTTP.
S>>В настоящий момент это — крайне неудобный RPC. Он создает массу проблем, и почти никаких не решает.
S>>"Настоящий" веб-сервис — это REST, т.е. использование addressability, connectedness, и statelesness.

C>А как REST решает поддержку транзакционности?
Никак. С точки зрения REST, 1 транзакция == 1 HTTP Request.
Чтобы обойти это ограничение, вводится дополнительный ресурс "транзакция", который за несколько запросов подготавливается, и затем одним запросом выполняется коммит.
C>Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?
Аутентификации — есть. Авторизации — нету, поскольку она за пределами протокола. Возврат информации об ошибке значительно более развит, чем в SOAP.
C>P.S. а что подразумевается под connectedness?
Возможность ссылаться из одного документа в другой.
REST веб-сервис позволяет до любого ресурса в рамках объектной дойти по ссылкам, начиная от service entry point.
Грубо говоря, в SOAP ты должен догадаться, что можно вызвать метод GetCustomers(), а потом передать один из ID полученных кастомеров в совершенно отдельный метод GetCustomerOrders(customerID).
А в REST ты получаешь, допустим, feed кастомеров, где каждая entry указывает на "страничку покупателя". Со странички покупателя на feed с его заказами ведет ссылка.
В итоге у тебя 2 способа получить доступ к некоторому ресурсу:
1. Сконструировать URL по заранее известным правилам
2. Проследовать до нужного ресурса, выбирая на каждом шагу нужную ссылку по определенным критериям

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>>>Такое словосочетание как API уже отменили?

PD>>Пожалуйста, подробнее об АПИ в плане разработки a.com. Что за АПИ они должны были сделать и как он должен бы выглядеть ? Вот у RSDN есть разные линки, по которым я могу попасть на ту или иную страницу. Это и есть АПИ ?

M>ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ

M>RSDN@Home умеет вытягивать данные с RSDN.ru? Умеет. Почему сервер некоег сервиса не может вытягивать данные с RSDN.ru абсолютно таким же образом?

Прекрасно. Именно что-то подобное я и хотел.

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

PD>>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?

M>Это зависит от сервисов. Google APIs вполне себе поверх REST живут. Предлагаю домашнее задание — изучить, что такое SOAP, и как с помощью него делаются запросы (hint: c помощью GET/POST)

Спасибо. Упражнение было выполнено примерно год назад, когда я программировал web-service

Hint : я же написал в письме к Sinclair, что я занимаюсь провокаторской деятельностью

Итак, в качестве одного из вариантов предлагается : c.com делает запросы к a.com (b.com) с помощью SOAP, используя при этом HTPP GET/POST. Правильно ? При этом a.com как-то определил свой интерфейс (SOAP), и c.com его знает, а поэтому может обратиться , используя этот интерфейс. Впрочем, можно и не SOAP, а что-то иное.

Я ничего не извратил ?

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

M>>(hint: c помощью GET/POST)
M>Имел в виду с их помощью в том числе. HTTP ничем не отличется от других протоколов взаимодействия

+1

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

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

PD>>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?

WF>Под SOAP имелся ввиду вариант SOAP over HTTP, как самый распространенный вариант. Дальше продолжать?

Нет. Блестяще. И ты, и Mamut пришли к одному и тому же и объяснили мне, неграмотному, как это должно выглядеть

А поэтому переадресую тебя вот сюда

http://www.rsdn.ru/forum/message/2900963.1.aspx

Просьба — подтверди свое согласие с тем, что я там написал.

C>Например:
C>http://en.wikipedia.org/wiki/WS-Transaction
C>http://en.wikipedia.org/wiki/WS-Security
C>http://msdn2.microsoft.com/en-us/webservices/aa740689.aspx

Ммм, я не буду вчитываться, давайте я предположу — смысл в том, что при наличии транзакции 1) клиенту передается некий токен 2) на сервере заводится сессия, которая болтается до таймаута или до коммита/роллбэка? В общем, так можно сделать поверх любого стейтлесс протокола, проблема в том, что это убийца масштабируемости и производительности.

C>Кроме того, SOAP не привязано к HTTP/HTTPS в отличии от REST. Главный смысл SOAP и Web Services в стандартизации общения между сервисами + наличие инструментов, которые позволяют автоматизировать часть работы.

Как правило, ничего кроме HTTP/HTTPS ничего не нужно, так как это единственное, что открыто.

C>Конечно всегда можно создать REST решение, превосходящее во всех отношениях SOAP и "WS-*", вопрос лишь во времени разработки и удобства использования.

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

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

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

PD>>Пусть так.

S>>>6. Сервер a.com принимает этот запрос и формирует ответ.

PD>>Подробнее, пожалуйста ? Шлет в ответ страницу ?
S>Как правило — да.

S>>>7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com

PD>>Во-во. Не уходи от этого ответа. Я ведь тебя 5 лет назад назначал разработчиком a.com, а сейчас я разрабатываю c.com, так что будь добр ответь мне, как там все это вытащить.
S>Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ.

Это когда он у тебя в сервис превратился ? До сих пор он вроде сервисом не был. Вот из твоего предыдущего письма

>5. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com. Этот момент не вполне понятен. Поскольку ты ничего не сказал про то, как устроен сервер a.com, мне трудно делать какие-либо предположения о том, как именно будет сформирован запрос. Получать форму с a.com большого смысла нет — если поменяется обработчик формы, то скорее всего изменится и сама форма. Поэтому скорее всего серверная часть приложения c.com отправит HTTP POST-запрос на известный ей адрес где-то на сервере a.com.

На этот POST запрос придет страница, ты же чуть выше писал, что в сервер в ответ шлет страницу. Из того, что написано ниже, следует, что это XML страница. Так что то, что ты раньше писал

>7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com

аннулировано. В ответ шлется XML, в нем можно разбираться с помощью XPath, и никаких особенностей,связанных с форматом представления, выбранным a.com, быть не должно, потому что абсолютно непонятно — особенностей по сравнению с чем ? Вот если бы в ответ HTML прислали — особенностей было бы сколько угодно.

>Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.

Насколько я понимаю, коли уж до XPath дело дошло, то эта страница XML. Итак, суммирую.

c.com делает некий запрос к a.com, который представляет собой сервис. Этот запрос делается с помощью web-клиента. В ответ a.com посылает некий XML, в котором ты потом с помощью XPath разберешься. Все верно ?

PD>>Кстати, твоя страница еще картинку с этим продуктом шлет и прочее. Мне это без надобности, расскажи, как отфильтровать.
S>Из упоминания картинки я делаю вывод, что HTML ты тоже не знаешь.

Антон. я же вчера честно предупредил, что занимаюсь провокаторской деятельностью

>Дело в том, что "картинку" страница не отсылает. Картинка в ней присутстует в виде ссылки. Веб браузер ее автоматически вытаскивает, а мой сервис c.com этого делать не будет. Поэтому никакого "отфильтровать" не надо.

Спасибо

Однако отмечу, что ты уже убрал HTML ответ и заменил его XML ответом. В нем, естественно, никакого <img нет. Мне просто было интересно узнать, как ты HTML парсить собираешься в ответ

S>>>8. После этого c.com отсылает по протоколу HTTP новый запрос к b.com, передавая данные, полученные от пользователя и a.com

PD>>Ну это ясно.

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

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

S>Оба варианта приведены для случая, когда разработчики a и b не осознавали популярности своих услуг, и делали исключительно человеко-ориентированные приложения. В реальной жизни у обоих сервисов есть один или несколько HTTP-based API.
S>Если они разработаны в конце девяностых, то это будет банальный HTTP POST, где и запрос и ответ представлены в виде пар ключ=значение. Такой протокол поддерживает большинство платежных систем — по историческим причинам.
S>Если разрабатывались в 2000-2003, то скорее всего будет применено что-то типа XML-RPC. В 2003-2006 был в моде SOAP. В 2007-2008 начинается восход архитектуры REST и микроформатов; а также всякая экзотика вроде JavaScript API. Эти API обычно документированы, что позволяет мне легко интегрировать их услуги в свое приложение.

Все! Прекрасно! Варианты (SOAP или что-то иное) рассматривать не будем, несущественно это. И ты, и Mamut и WFrag в конце концов пришли к одному и тому же. А поэтому замкну я этот кусочек дерева и сделаю граф.

Вот здесь я суммировал все.

http://www.rsdn.ru/forum/message/2900963.1.aspx

Здесь и продолжу, когда получу подтверждение.

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

PD>>Прекрасно. Я действительно ничего не сказал. АПИ, который тут требуют другие, не определен. А посему куда именно твой web-клиент обратится, я тоже не знаю. Но и определять я его не буду — не мое же решение, а твое. Определи как хочешь и расскажи, как. Назначаю тебя на некоторое время разработчиком a.com. Только имей в виду, что c.com будет делаться через 5 лет, а может, и вообще не будет. Ты о нем ничего не знаешь.

M>И как это веб до сих работает, ума не приложу

И как это Windows 9x до сих пор кое у кого работает, ума не приложу. До ужаса кривая внутренняя архитектура. А работает ведь!

M>Сервис c.com создается не в вакууме, и сервисы a.com и b.com тоже существуют не в вакууме. Самый крайний случай — это выдирание и парсинг HTML'я (web-scraping), но это действительно самый крайний случай.

Мы уже пришли к XML/SOAP, зачем будем обратно к HTML возвращаться, да еще парсить его, да еще там, чего доброго, JavaScript.

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

ГВ>И правильно. Поскольку это есть узел распределённой информационной системы. Что он делает, по каким протоколам с кем-то ещё связывается — вопрос очень сильно отдельный. "Сервер", это же не награда за доблесть, а просто роль (как, кстати, это правильно отметил Sinclair) в определённых взаимодействиях. Скажу больше, в рамках одной транзакции узлы А и Б могут резко поменяться ролями и не один раз. Соответственно, на одном физическом компьютере (или кластере) могут исполняться программы, выполняющие как роль серверов (предоставление сервисов), так и роль клиентов (запрос данных, использование других сервисов). Дальше банальная формальная логика: некий компьютер может выполнять преимущественно серверные функции, и потому его можно обобщённо назвать "сервером". Но из того, что его назвали "сервером" ещё не следует, что этот компьютер выполняет только серверные функции.

Замечательно. Вполне согласен.

PD>>>>А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать.
M>>>И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда.
PD>>Да, только функционал его резко возрастает и становится не серверным.

ГВ>И славно! Как минимум, пользователь избавлен от необходимости апдейтить своё приложение, если a.com и b.com надумали поменять API, добавить/убрать услуги и т.п. Всем этим централизованно занимается обслуга c.com.

А вот с этим не очень. Но отвечу позже.

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

PD>Итак, в качестве одного из вариантов предлагается : c.com делает запросы к a.com (b.com) с помощью SOAP, используя при этом HTPP GET/POST. Правильно ? При этом a.com как-то определил свой интерфейс (SOAP), и c.com его знает, а поэтому может обратиться , используя этот интерфейс. Впрочем, можно и не SOAP, а что-то иное.

PD>Я ничего не извратил ?

Да. Вполне реальный вариант.

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

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

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

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

ГВ>В качестве критики воспользуюсь благородным древним слогом: "Галимый отстой! Это же 2-уровневая система! Да ещё и с толстым клиентом! А если сервер поменяется?

Какой сервер ? a.com ? Что именно поменялось ? Сам сервер превратился в d.com, или в нем что-то поменялось ?

Hint : если у тебя вместо Windows вдруг появился на машине Linux, то это значит, что у тебя действительно что-то поменялось всерьез. Но если ты проапгрейдил Windows 2000 до XP — я вообще-то могу считать, что у тебя все, что было, осталось, правда, кое-что добавилось.

>Что? Всех клиентов обновлять? Щаззз, разбежался! Маздай!!! Эн-тайер рулит форевер!"

Ну-ну...

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

PD>>Я ничего не извратил ?

WF>Да. Вполне реальный вариант.

Ok. Жду подтверждения от Mamut и Sinclair.

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

PD>Какой сервер ? a.com ? Что именно поменялось ? Сам сервер превратился в d.com, или в нем что-то поменялось ?

Интерфейс сервиса, например. Запросто.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Во-во. Не уходи от этого ответа. Я ведь тебя 5 лет назад назначал разработчиком a.com, а сейчас я разрабатываю c.com, так что будь добр ответь мне, как там все это вытащить.
S>>Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ.

PD>Это когда он у тебя в сервис превратился ? До сих пор он вроде сервисом не был. Вот из твоего предыдущего письма
Легким манием руки я превратил его в сервис. Практически любое веб-приложение (предназначенное для человека) при желании можно превратить в сервис (службу, предназначенную для испольхнвания софтом).

>>7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com

PD>аннулировано. В ответ шлется XML, в нем можно разбираться с помощью XPath, и никаких особенностей,связанных с форматом представления, выбранным a.com, быть не должно, потому что абсолютно непонятно — особенностей по сравнению с чем ? Вот если бы в ответ HTML прислали — особенностей было бы сколько угодно.

>>Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.

PD>Насколько я понимаю, коли уж до XPath дело дошло, то эта страница XML. Итак, суммирую.
Нет. Я же написал — применяю SGML reader для того, чтобы превратить произвольный HTML, который отдается с сервиса a.com и скорее всего показывается людям исключительно благодаря quirks mode браузера, в DOM, пригодный для анализа.

PD>c.com делает некий запрос к a.com, который представляет собой сервис. Этот запрос делается с помощью web-клиента. В ответ a.com посылает некий XML, в котором ты потом с помощью XPath разберешься. Все верно ?
Всё, кроме ограничения на XML. Повторяю еще раз:

Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ. Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.

PD>Спасибо

Я написал способ парсинга HTML с самого начала. Меня начинает утомлять повторение общеизвестных истин.

PD>Все! Прекрасно! Варианты (SOAP или что-то иное) рассматривать не будем, несущественно это. И ты, и Mamut и WFrag в конце концов пришли к одному и тому же. А поэтому замкну я этот кусочек дерева и сделаю граф.

PD>Вот здесь я суммировал все.

PD>http://www.rsdn.ru/forum/message/2900963.1.aspx

PD>Здесь и продолжу, когда получу подтверждение.

... << RSDN@Home 1.2.0 alpha rev. 677>>

PD>На этот POST запрос придет страница, ты же чуть выше писал, что в сервер в ответ шлет страницу. Из того, что написано ниже, следует, что это XML страница. Так что то, что ты раньше писал

Нет, не следует. Приходит (в общем случае) инвалидная HTML страница, которую мы превращаем в валидный XHTML и потом разбираем.

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

PD>Ok. Жду подтверждения от Mamut и Sinclair.
Лично я свое "подтверждение" озвучил еще вчера. Цитирую:

В реальной жизни у обоих сервисов есть один или несколько HTTP-based API.
Если они разработаны в конце девяностых, то это будет банальный HTTP POST, где и запрос и ответ представлены в виде пар ключ=значение. Такой протокол поддерживает большинство платежных систем — по историческим причинам.
Если разрабатывались в 2000-2003, то скорее всего будет применено что-то типа XML-RPC. В 2003-2006 был в моде SOAP. В 2007-2008 начинается восход архитектуры REST и микроформатов; а также всякая экзотика вроде JavaScript API. Эти API обычно документированы, что позволяет мне легко интегрировать их услуги в свое приложение.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

ГВ>>В качестве критики воспользуюсь благородным древним слогом: "Галимый отстой! Это же 2-уровневая система! Да ещё и с толстым клиентом! А если сервер поменяется?

PD>Какой сервер ? a.com ? Что именно поменялось ? Сам сервер превратился в d.com, или в нем что-то поменялось ?

Да, a.com. Или b.com. Поменялся интерфейс, предоставляемый одним из этих серверов. Интерфейс в широком смысле этого слова: допустим, изменились соглашения о бинарном формате данных, доступных по обычному TCP/IP. Или поменялся порядок вызовов в каких-нибудь транзакциях. Или, что чаще всего — расширилась функциональность и теперь очень хочется эту самую расширившуюся функциональность дать нашим пользователям.

PD>Hint : если у тебя вместо Windows вдруг появился на машине Linux, то это значит, что у тебя действительно что-то поменялось всерьез. Но если ты проапгрейдил Windows 2000 до XP — я вообще-то могу считать, что у тебя все, что было, осталось, правда, кое-что добавилось.

Как ты понимаешь, я, как настоящий джедай, думаю сейчас про простых человечков, не наделённых Силой, которых нужно спасать от вселенского зла по имени "Сопровождение".

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

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

PD>Hint : я же написал в письме к Sinclair, что я занимаюсь провокаторской деятельностью

То есть это означает, что лучше тут дискуссию с тобой не вести, я ничего не извратил?

PD>Итак, в качестве одного из вариантов предлагается : c.com делает запросы к a.com (b.com) с помощью SOAP, используя при этом HTPP GET/POST. Правильно ? При этом a.com как-то определил свой интерфейс (SOAP), и c.com его знает, а поэтому может обратиться , используя этот интерфейс. Впрочем, можно и не SOAP, а что-то иное.

Да.
При этом тебе несколько раз указали (но ты то ли не понял, то ли занялся провокаторской деятельностью) что даже если а и б не предоставляют API, а воспользоваться хочется все же именно ими, то всегда есть крайний случай — парсить HTML (если они не сервисы, то они приложения и дают HTML с результатами для клиента). Не очень приятный и надежный способ, но справиться с ним можно. Многие тут, думаю, подобным занимались и я в том числе. Повторяю — это крайний случай.

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

Ну и в целом по теме — главное в веб-приложениях, что они не требуют ничего кроме браузера. А браузеры сейчас распространены повсеместно. Значит, что я купив ноут в магазине сразу же могу использовать Gmail. Мне не нужно ничего скачивать, устанавливать, потом удалять — все же сделано и установлено.
И придя на работу и откры Gmail я виже его в точности таким же, каким я настроил из дома. И придя к заказчикам, и если вдруг захотелось посмотреть почту — на юбом чужом компьютере я могу это сделать и не замусорить его неинтересными владельцу программами. Это очень, очень удобно. И это определяет успех приложений. Потому что они удобны клиентам. А какая там архитектура — это уже второй вопрос. Деньги платят клиенты и развитие идет туда, где деньги. Архитектура — это хорошо, но вторично. Никому не нужны красивые программы, написанные ради самих себя из чистого искусства. Поэтому предлагаемые изменения в архитектуре должны обеспечить в точности те же удобства для пользователей. Тогда будет иметь смысл сравнивать эти решения. Но сравнивать архитектуру "классического десктоп"-приложения и веб-приложения бессмысленно, у них разная функциональность, разные плюсы и минусы. Мне архитектура яблока нравится больше архитектуры ананаса (чистить проще), но одно другое заменяет не очень.

Так, личный опыт (не претендует на универсальность):
Наша компания пишет корпоративный софт на заказ для относительно крупных российских компаний. Т.е. работающий только внутри компании заказчика. Так вот за последние 4 года было написано, я уж не помню точно, то ли одно, то ли целых два десктоп приложений. Все остальное — веб. Заказчики у нас требуют веб-приложения для работы внутри компании. Именно из-за простоты развертывания и поддержки. Сперва, я помню мы предлагали делать толстые десктоп клиенты, всякие click-one развертывания, сейчас и не предлагаем — не берут, т.к. их полностью устраивает решение с веб-интерфейсом...
Кстати, из тех двух десктоп-приложений сейчас в поддержке осталось только одно и в нем уже часть функционала выползла в веб-сервисы, которыми пользуются и другие приложения. Т.е. десктоп там остался в основном интерфейс...

ГВ>Самые ужасные изменения, это не изменения платформ. Это как раз чепуха. Самое жуткое, это, например, добавление одного параметра в один-единственный вызов. Вот это — сущий кошмар и страшный сон. Потому что платформы меняются раз в пару лет, а параметры — по два раза на дню. Тем паче, что по условиям задачи ни a.com, ни b.com друг о друге знать не знают, а наш c.com в упор не видят. Соответственно, каждый пытается непрерывно расширять и улучшать предоставляемый сервис. С какой интенсивностью они будут это делать — неизвестно, но лучше предполагать, что с большой.

Если предполагать, что с большой, лучше в явном виде попросить у них API или использовать более вменяемых конкурентов. Но на самом деле, скорость внесения изменений ограничена природой, по этому совсем страшно не бывает. Стабильный массовый сервис не может часто менять API.

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

HB>>Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

PD>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Какой ответ-то? Информацию с a.com? Если так, то это зависит от того, как именно он её выдаёт. Тут, вообще-то, много формулировок для объяснений "как" может быть...

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

PD>>Просьба — еще одну итерацию. Только опять полный текст. Не надо формы приводить, несущественно это. Словами опиши. Но полное решение. И подпишись

Вот кстати реальный пример того, что ты описываешь

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>Легким манием руки я превратил его в сервис.

Ох, что-то плохо верится. Напоминаю — ты его писал 5 лет назад, и о том. что это сервис — не знал. И кроме того, у меня (автора c.com) нет сейчас возможности сделать из a.com сервис. Ну да ладно. Итак, a.com есть сервис.

PD>>Насколько я понимаю, коли уж до XPath дело дошло, то эта страница XML. Итак, суммирую.
S>Нет. Я же написал — применяю SGML reader для того, чтобы превратить произвольный HTML, который отдается с сервиса a.com и скорее всего показывается людям исключительно благодаря quirks mode браузера, в DOM, пригодный для анализа.

Ну что же, продолжим. Во-первых, на c.com потребовался SGML reader. Я с ним и вправду не знаком. Положим, этот SGML в состоянии этот произвольный HTML, содержащий, возможно, еще и JavaScript, превратить в DOM, пригодный для анализа. Не совсем, правда, ясно, по каким критериям ты потом будешь в этом DOM искать габариты и стоимость. Поясни.

S>

Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ. Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.

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

S>Я написал способ парсинга HTML с самого начала. Меня начинает утомлять повторение общеизвестных истин.

Можно детальнее ? Все же, по каким критериям ты определишь, где именно габариты ?

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
    <head>
        <title>Product</title>
    </head>
    <body>
        Name 
     <br>
        Elephant
     <br>
        Height
     <br>
        120
    </body>
</html>

У тебя есть основание утверждать, что 120 — это высота ? Какое ?

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

S>>

Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ. Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.

PD>Ну или поясни, как ты с помощью Regex или еще чего-то определишь в исходном HTML или в XML, где именно габариты.

ИМХО, ты уже передёргивать начинаешь...

S>>Я написал способ парсинга HTML с самого начала. Меня начинает утомлять повторение общеизвестных истин.

PD>Можно детальнее ? Все же, по каким критериям ты определишь, где именно габариты ?

В точности по тем же самым, по которым они определяются клиентским приложением из твоего варианта решения.

PD>У тебя есть основание утверждать, что 120 — это высота ? Какое ?

Например, вручную проанализировали содержание, потом настроили наши ридеры.

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

dmz>Если предполагать, что с большой, лучше в явном виде попросить у них API или использовать более вменяемых конкурентов. Но на самом деле, скорость внесения изменений ограничена природой, по этому совсем страшно не бывает. Стабильный массовый сервис не может часто менять API.

Ну вот уж прямо и утрировать слегка нельзя!

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

F>Ну и в целом по теме — главное в веб-приложениях, что они не требуют ничего кроме браузера. А браузеры сейчас распространены повсеместно. Значит, что я купив ноут в магазине сразу же могу использовать Gmail. Мне не нужно ничего скачивать, устанавливать, потом удалять — все же сделано и установлено.

А ссылку на приложение откуда брать будешь? Находить в интернете и тыкать в нее. В случае десктопа точно также будешь тыкать в ссылку с инсталлятором.

F>И придя на работу и откры Gmail я виже его в точности таким же, каким я настроил из дома. И придя к заказчикам, и если вдруг захотелось посмотреть почту — на юбом чужом компьютере я могу это сделать и не замусорить его неинтересными владельцу программами. Это очень, очень удобно. И это определяет успех приложений. Потому что они удобны клиентам.

А чтобы пользоваться корпоративным ящиком будешь запускать клиента или пользоваться веб-мордой почтовика, установленного на работе. Выигрывая в одном, ты теряешь в другом (в универсальности), и это другое объективно важнее.

F>Наша компания пишет корпоративный софт на заказ для относительно крупных российских компаний. Т.е. работающий только внутри компании заказчика. Так вот за последние 4 года было написано, я уж не помню точно, то ли одно, то ли целых два десктоп приложений. Все остальное — веб. Заказчики у нас требуют веб-приложения для работы внутри компании. Именно из-за простоты развертывания и поддержки. Сперва, я помню мы предлагали делать толстые десктоп клиенты, всякие click-one развертывания, сейчас и не предлагаем — не берут, т.к. их полностью устраивает решение с веб-интерфейсом...

Если они экономят на админах, пусть переплачивают за стоимость разработки.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

F>Вообще Павел, я надеюсь ты за ночь отдохнул и мозги проветрились. И лучше сегодня не занимайся "провокаторской деятельностью", а подумай о том, что тебе написали. Ты упорно требовал от Sinclair решения через веб-аппликейшен, но так и не привел решения в виде десктоп приложения. А ведь оно в точности такое же будет, как и веб-решение, за исключением пользовательского интерфейса. Если думаешь, что нет — напиши нам решение, сам убедишься.

Я могу привести решение в виде клиентского приложения. Проблема с сервисами a.com и b.com в том, что если они не рассчитаны на использование роботами,
и имеют сложный интерфейс, а так же какие-то данные рассчитываются джаваскриптом — то единственный способ с ними надежно работать — на клиенте.
Т.е. открывает a.com и b.com в браузере (браузерах), допустим в скрытых фреймах, работает с ними при помощи JS, имитируя действия клиента, потом джаваскриптом-же собирает данные из DOM, потом что-то с ними делает. С браузером этот трюк не выйдет, так как есть защита от XSS, но если сделать своего клиента, который будет использовать несколько инстансов браузера или похаченный браузер — то все будет работать.

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

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

S>>Легким манием руки я превратил его в сервис.

PD>Ох, что-то плохо верится. Напоминаю — ты его писал 5 лет назад, и о том. что это сервис — не знал. И кроме того, у меня (автора c.com) нет сейчас возможности сделать из a.com сервис. Ну да ладно. Итак, a.com есть сервис.

Любой сайт есть сервис, потому что отдает данные по протоколу. Если характер данных и формат протокола не меняются десять раз в день.

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

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

PD>>Hint : я же написал в письме к Sinclair, что я занимаюсь провокаторской деятельностью

F>То есть это означает, что лучше тут дискуссию с тобой не вести, я ничего не извратил?

. Лучше не надо. Мне пока что вполне хватает Mamut, WFRag и Sinclair. Честно говоря, я и так не успеваю отвечать.

F>При этом тебе несколько раз указали (но ты то ли не понял, то ли занялся провокаторской деятельностью) что даже если а и б не предоставляют API, а воспользоваться хочется все же именно ими, то всегда есть крайний случай — парсить HTML (если они не сервисы, то они приложения и дают HTML с результатами для клиента). Не очень приятный и надежный способ, но справиться с ним можно. Многие тут, думаю, подобным занимались и я в том числе. Повторяю — это крайний случай.

Вот сейчас мы с Sinclair и продолжаем его парсить. Но (если серьезно) — то, что это крайний случай — это полбеды. Хуже, что это ненадежный способ. Он не дает никаких гарантий, что результат будет верен.

F>Вообще Павел, я надеюсь ты за ночь отдохнул и мозги проветрились. И лучше сегодня не занимайся "провокаторской деятельностью", а подумай о том, что тебе написали. Ты упорно требовал от Sinclair решения через веб-аппликейшен, но так и не привел решения в виде десктоп приложения. А ведь оно в точности такое же будет, как и веб-решение, за исключением пользовательского интерфейса. Если думаешь, что нет — напиши нам решение, сам убедишься.

Напишу. Будет. Но все же чуть позже, дай мне от Синклера все же ответ получить

Прочие аргументы прочитал. Со многим можно согласиться, кое с чем нет.

>Так вот за последние 4 года было написано, я уж не помню точно, то ли одно, то ли целых два десктоп приложений. Все остальное — веб. Заказчики у нас требуют веб-приложения для работы внутри компании. Именно из-за простоты развертывания и поддержки.

Ну вообще-то не столько заказчик хочет, сколько его научили это хотеть. Но вообще-то я ничего не имею против самих web-приложений. Просто , как я уже писал, должны быть просто приложения — с web-компонентой, с e-mail компонентой, с графичсекой компонентой и т.д. Просто приложения.

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

ГВ>Какой ответ-то? Информацию с a.com? Если так, то это зависит от того, как именно он её выдаёт. Тут, вообще-то, много формулировок для объяснений "как" может быть...

Во-во. С WFrag и Mamut мы уже вроде пришли к согласию, что у a.com должен быть XML (или не XML) API, с помощью которого можно запросы делать и ответы получать. Синклер все еще хочет HTML страницу с a.com получать и ее парсить. Подожем немного

F>Наша компания пишет корпоративный софт на заказ для относительно крупных российских компаний. Т.е. работающий только внутри компании заказчика. Так вот за последние 4 года было написано, я уж не помню точно, то ли одно, то ли целых два десктоп приложений. Все остальное — веб. Заказчики у нас требуют веб-приложения для работы внутри компании. Именно из-за простоты развертывания и поддержки. Сперва, я помню мы предлагали делать толстые десктоп клиенты, всякие click-one развертывания, сейчас и не предлагаем — не берут, т.к. их полностью устраивает решение с веб-интерфейсом...
F>Кстати, из тех двух десктоп-приложений сейчас в поддержке осталось только одно и в нем уже часть функционала выползла в веб-сервисы, которыми пользуются и другие приложения. Т.е. десктоп там остался в основном интерфейс...

+1
Сам недавно переделал одно десктоп приложение таким образом, что от него только GUI остался, а бизнес-логика вся ушла в веб-сервер (общение идет в XML по HTTP). Нужно это приложение только для того чтобы посылать Windows messages другим программам, а так давно бы его упразднили.. Я не говорю что десктоп приложения устарели и стали ненужными, просто некоторые направления автоматизации плавно мигрируют в web. Десктоп приложения жили и будут жить всегда в том или ином виде. Например, тот же браузер

. Просто есть задачи для которых web технология подходит лучше, как здесь уже писали.

Павел, хватит уже технические аспекты обмусоливать, а то мыслей из-за этого не видно

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

F>>Наша компания пишет корпоративный софт на заказ для относительно крупных российских компаний. Т.е. работающий только внутри компании заказчика. Так вот за последние 4 года было написано, я уж не помню точно, то ли одно, то ли целых два десктоп приложений. Все остальное — веб. Заказчики у нас требуют веб-приложения для работы внутри компании. Именно из-за простоты развертывания и поддержки. Сперва, я помню мы предлагали делать толстые десктоп клиенты, всякие click-one развертывания, сейчас и не предлагаем — не берут, т.к. их полностью устраивает решение с веб-интерфейсом...

LP>Если они экономят на админах, пусть переплачивают за стоимость разработки.

Веб-приложения разрабатывать дешевле. Hosted-веб приложения — еще дешевле. Экономия выходит во всём.

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

PD>Во-во. С WFrag и Mamut мы уже вроде пришли к согласию, что у a.com должен быть XML (или не XML) API, с помощью которого можно запросы делать и ответы получать. Синклер все еще хочет HTML страницу с a.com получать и ее парсить. Подожем немного

Никому он не должен. Я говорю, что SOAP -- просто один из вариантов. Вариант с разбором HTML тоже не редкость. Мне, в общем-то, как разработчику более-менее все равно -- благо для работы с разными протоколами написано уже много чего, более чем достаточно.

Ну, вообще-то, Синклер не только про расковыривание HTML говорил.

В прочем, ладно, подождём.

Хм. Силён

Аргумент действительно хороший. Правда, никто не мешает то же самое делать на сервере (хостить закастомизированный браузер) — масштабируемость правда будет ни к чёрту, ну да у нас же крайний случай

... << RSDN@Home 1.2.0 alpha rev. 717>>

PD>>>Я ничего не извратил ?

WF>>Да. Вполне реальный вариант.

PD>Ok. Жду подтверждения от Mamut и Sinclair.

Да. Этот вариант был давно озвучен

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>Ох, что-то плохо верится. Напоминаю — ты его писал 5 лет назад, и о том. что это сервис — не знал. И кроме того, у меня (автора c.com) нет сейчас возможности сделать из a.com сервис.
В третий раз повторяю: я написал тебе решения для случая, когда пять лет назад a.com был написан без малейшего желания предоставлять машинно-читаемый сервис. Это я его использую не по назначению, благодаря тому, что и протокол и формат, по которым он работает, подчиняются некоторым общеизвестным правилам. Написав парсер его результатов, я превратил приложение в сервис.

PD>Ну что же, продолжим. Во-первых, на c.com потребовался SGML reader. Я с ним и вправду не знаком. Положим, этот SGML в состоянии этот произвольный HTML, содержащий, возможно, еще и JavaScript, превратить в DOM, пригодный для анализа. Не совсем, правда, ясно, по каким критериям ты потом будешь в этом DOM искать габариты и стоимость. Поясни.
Поясняю: посмотрев глазами на source страницы, отдаваемой мне приложением a.com, я при помощи мозга придумаю XPath либо Regex выражения, которые вытаскивают нужные мне данные, и заставлю руки их написать.

PD>Можно детальнее ? Все же, по каким критериям ты определишь, где именно габариты ?
Павел, невозможно написать анализатор неизвестно чего. Будет настоящее приложение — будет и задача по разбору его результата.

PD>

PD>!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
PD><html>
PD>    <head>
PD>        <title>Product</title>
PD>    </head>
PD>    <body>
PD>        Name 
PD>     <br>
PD>        Elephant
PD>     <br>
PD>        Height
PD>     <br>
PD>        120
PD>    </body>
PD></html>

PD>

Ок, вот теперь мы можем начать scrap-ить страничку.

var heightExpression = new Regex(@"(?<=Height\D+)\d+");

Как-то так.
PD>У тебя есть основание утверждать, что 120 — это высота ? Какое ?
Перед ней непосредственно выведен текст "Height". Из прочтения инструкции по пользованию приложением a.com, которая там рядом неизбежно расположена, а также из других источников, я заключаю, что это высота товара в дюймах.

... << RSDN@Home 1.2.0 alpha rev. 677>>

M>>Сервис c.com создается не в вакууме, и сервисы a.com и b.com тоже существуют не в вакууме. Самый крайний случай — это выдирание и парсинг HTML'я (web-scraping), но это действительно самый крайний случай.

PD>Мы уже пришли к XML/SOAP, зачем будем обратно к HTML возвращаться, да еще парсить его, да еще там, чего доброго, JavaScript.

Кто пришел к HTML? О HTML вообще никто ни разу не упомянул вообще. c.com вытягивает данные с b.com и a.com — где в этой вразе говорится о HTML? Про заполнение веб-форм и парсинг ответа совсем не мы говорили

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

Ну то есть эта проблема тоже более чем решаема.

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

L>Хм. Силён

Ха! Да я бы рад захостить, и пробовал. Но. Сколько надо инстансов браузера, что бы все это надежно работало? Как они должны жить? Короче, не живет это под нагрузкой, или это такоой гиморой. Что оказалось проще написать псевдо-интерпретатор джаваскрипта, чем такое делать. Плавали, знаем.

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

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

PD>>Ok. Жду подтверждения от Mamut и Sinclair.
S>Лично я свое "подтверждение" озвучил еще вчера. Цитирую:
S>

В реальной жизни у обоих сервисов есть один или несколько HTTP-based API.
S>Если они разработаны в конце девяностых, то это будет банальный HTTP POST, где и запрос и ответ представлены в виде пар ключ=значение. Такой протокол поддерживает большинство платежных систем — по историческим причинам.
S>Если разрабатывались в 2000-2003, то скорее всего будет применено что-то типа XML-RPC. В 2003-2006 был в моде SOAP. В 2007-2008 начинается восход архитектуры REST и микроформатов; а также всякая экзотика вроде JavaScript API. Эти API обычно документированы, что позволяет мне легко интегрировать их услуги в свое приложение.

Ok.

Итак, ты согласился, что здесь будет некий API, то ли XML-RPC, то ли SOAP, то ли REST. Поэтому часть дискуссии, где предлагалось парсить HTML, будем считать отныне несущественной.

Суммирую все окончательно.

Клиент делает запрос к c.com. c.com, зная некий API, предоставляемый a.com (например, XML — RPC), выполняет клиент-серверную операцию, выступая при этом в роли клиента. Получив данные от a.com, он их аннализирует, формирует новый запрос , теперь к b.com, где также выступает в роли клиента. Запросы и ответы идут в виде неких XML или иных пакетов. Получив ответ от b.com, он формирует страницу (теперь уж HTML) и шлет ее клиенту, начавшему операцию.

Вроде все верно, надеюсь.

Теперь у меня вопросы.

1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.
2. Что полезного делает c.com вообще ? Он выступает в роли сервера по отношению к клиенту, и, получив от него запрос, выполняет две операции, в которых сам выступает клиентом, а потом отсылает результаты собственно клиенту. Почему собственно клиент не мог эти два запроса сделать сам ? Или сформулирую иначе. Почему клиент сам не является для себя c.com ? Почему, если запросы к a.com и b.com будут делаться с клиента — это плохо, а вот если мы тут промежуточную конструкцию заведем — это будет хорошо ?
3. В продолжение п.2 Если функциональность клиента резко усложняется (например, уже не три строки отослать или получить, а десятки или сотни Кб) — зачем нужен лишний трафик ? Зачем c.com будет запрашивать сотню Кб с a.com, другую сотню с b.com и отылать все это клиенту, почему клиент не может сам эти Кб получить от a.com и b.com ?
4. На клиенте доступны все средства, предоставляемые операционной системой клиента. Например, можно реагировать на нажатия некоторой клавиши, что в Windows и Linux делается не совсем одним и тем же способом

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

Короче — что тут полезного c.com делает ? Напоминаю, он придуман не мной, а моими оппонентами для решения именно той задачи, которую я поставил. Поэтому всякие аргументы типа превращения c.com в универсальный построитель запросов неизвестно куда — приниматься не будут.

WF>Хе-хе. Вот как раз такой случай у меня. Просто вешаем на сервер c.com прокси для AJAX-запросов и всё

Ну то есть эта проблема тоже более чем решаема.

malev.com

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

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

dmz>Я могу привести решение в виде клиентского приложения. Проблема с сервисами a.com и b.com в том, что если они не рассчитаны на использование роботами,
dmz>и имеют сложный интерфейс, а так же какие-то данные рассчитываются джаваскриптом — то единственный способ с ними надежно работать — на клиенте.

Уф! Наконец-то! Именно к этому я и веду.

dmz>Т.е. открывает a.com и b.com в браузере (браузерах), допустим в скрытых фреймах, работает с ними при помощи JS, имитируя действия клиента, потом джаваскриптом-же собирает данные из DOM, потом что-то с ними делает. С браузером этот трюк не выйдет, так как есть защита от XSS, но если сделать своего клиента, который будет использовать несколько инстансов браузера или похаченный браузер — то все будет работать.

Ну ин так. Ты сумел исхитриться с помощью скрытых фрейсов или похаченного браузера. Я бы просто специализированное окно открыл (может, видимое, может нет, может, поток , а не окно)(может, и в процессе браузер, не важно это) и в нем все сделал. Как — детали, несущественно. Но скорее всего — просто шлем a.com запрос в виде некоего XML (к примеру), получаем от него ответ в виде XML и т.д. Пользователь ничего не видит. А результат — может быть, можно и в окне броузера показать, а можно в окне.

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

M>>>Сервис c.com создается не в вакууме, и сервисы a.com и b.com тоже существуют не в вакууме. Самый крайний случай — это выдирание и парсинг HTML'я (web-scraping), но это действительно самый крайний случай.

PD>>Мы уже пришли к XML/SOAP, зачем будем обратно к HTML возвращаться, да еще парсить его, да еще там, чего доброго, JavaScript.

M>Кто пришел к HTML? О HTML вообще никто ни разу не упомянул вообще. c.com вытягивает данные с b.com и a.com — где в этой вразе говорится о HTML? Про заполнение веб-форм и парсинг ответа совсем не мы говорили

Да ты же пятью строчками выше. Или я тебя не понял ? Впрочем, это не важно, тема HTML вроде закрыта.

L>>Хм. Силён

dmz>Ха! Да я бы рад захостить, и пробовал. Но. Сколько надо инстансов браузера, что бы все это надежно работало? Как они должны жить? Короче, не живет это под нагрузкой, или это такоой гиморой. Что оказалось проще написать псевдо-интерпретатор джаваскрипта, чем такое делать. Плавали, знаем.

Ну и я о том же, да

Хотя — можно попробовать сделать много-много фреймов в одном браузере... Всё равно криво, но уже на порядок полегше...

... << RSDN@Home 1.2.0 alpha rev. 717>>

dmz>>Я могу привести решение в виде клиентского приложения. Проблема с сервисами a.com и b.com в том, что если они не рассчитаны на использование роботами,
dmz>>и имеют сложный интерфейс, а так же какие-то данные рассчитываются джаваскриптом — то единственный способ с ними надежно работать — на клиенте.

PD>Уф! Наконец-то! Именно к этому я и веду.

Это редкий, клинический случай. Более того, эта проблема решается по другому. Она решается административно. Мы или даем денег владельцам a.com что бы они
нам предоставили вменяемый интерфейс. Или взять с них денег и предоставить им вменяемый интерфейс, если они его сами делать не могут. Или дать денег тому, кто уже это сделал — ну, типа, Амадеусу. А вот когда нет денег или ресурсов — тогда и начинаются пляски; более того, использования клиента проблему не решит, а только усугубит.

Это я как практик говорю.

PD>Ну ин так. Ты сумел исхитриться с помощью скрытых фрейсов или похаченного браузера. Я бы просто специализированное окно открыл (может, видимое, может нет, может, поток , а не окно)(может, и в процессе браузер, не важно это) и в нем все сделал. Как — детали, несущественно. Но скорее всего — просто шлем a.com запрос в виде некоего XML (к примеру), получаем от него ответ в виде XML и т.д. Пользователь ничего не видит. А результат — может быть, можно и в окне броузера показать, а можно в окне.

Какого XML если a.com не имеет вменяемого интерфейса по условию? Если он принимает XML и отдает XML — то обозначенная мной проблема отсутствует, задача сама собой решилась.

L>Ну и я о том же, да

Хотя — можно попробовать сделать много-много фреймов в одном браузере... Всё равно криво, но уже на порядок полегше...

Это не работает. JS из одного фрейма не получит доступ к данным другого фрейма. Нужен похаченный браузер — например, в виде плагина к мозилле (GreaseMonkey) — но мы полностью теряем универсальность тогда; с какой стати наши клиенты будут обязаны пользоваться мозиллой или ставить плагины?

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

PD>>[/code]
S>Ок, вот теперь мы можем начать scrap-ить страничку.
S>

S>var heightExpression = new Regex(@"(?<=Height\D+)\d+");
S>

S>Как-то так.
PD>>У тебя есть основание утверждать, что 120 — это высота ? Какое ?
S>Перед ней непосредственно выведен текст "Height".

Ничего себе аргумент ! А если будет так

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
    <head>
        <title>Product</title>
    </head>
    <body>
        Name 
     <br>
        Elephant
     <br>
        Vertical Size
     <br>
      120
    </body>
</html>

А если сайт выдает страницу не на английском ? Как там по португальски "высота" ?

>Из прочтения инструкции по пользованию приложением a.com, которая там рядом неизбежно расположена,

У сайтов всегда есть инструкции по их пользованию ? Что-то я не припомню на сайтах таких инструкций — хорошо еще , если карту сайта приведут. Мы ведь о парсинге HTML говорим вроде, так, не о XML-RPC или SOAP. Вот там, да, инструкция будет.

>а также из других источников

И какие же другие источники у тебя есть , когда ты получил эту страницу и ничего больше ?

>, я заключаю, что это высота товара в дюймах.

Которая в ходе такого анализа вполне может оказаться в действительности расстоянием от штаб-квартиры компании до Нью_Йорка.

PD>Уф! Наконец-то! Именно к этому я и веду.
Этот случай — клинический. Строить на нём доказательство чего-либо ну совсем нелогично.

PD>Ну ин так. Ты сумел исхитриться с помощью скрытых фрейсов или похаченного браузера. Я бы просто специализированное окно открыл (может, видимое, может нет, может, поток , а не окно)(может, и в процессе браузер, не важно это) и в нем все сделал. Как — детали, несущественно. Но скорее всего — просто шлем a.com запрос в виде некоего XML (к примеру), получаем от него ответ в виде XML и т.д. Пользователь ничего не видит. А результат — может быть, можно и в окне броузера показать, а можно в окне.
Э.... А подробнее? При чём тут какой-то XML? Я честно говоря ничего не понял — что за решение ты предлагаешь?

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

PD>Клиент делает запрос к c.com. c.com, зная некий API, предоставляемый a.com (например, XML — RPC), выполняет клиент-серверную операцию, выступая при этом в роли клиента. Получив данные от a.com, он их аннализирует, формирует новый запрос , теперь к b.com, где также выступает в роли клиента. Запросы и ответы идут в виде неких XML или иных пакетов. Получив ответ от b.com, он формирует страницу (теперь уж HTML) и шлет ее клиенту, начавшему операцию.

PD>Вроде все верно, надеюсь.

PD>Теперь у меня вопросы.

PD>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.

Про HTTP вспомнили, потому что разговор заведён про web-приложения. Что ж тут удивительного? Вспоминали и про бинарные форматы.

PD>2. Что полезного делает c.com вообще ? Он выступает в роли сервера по отношению к клиенту, и, получив от него запрос, выполняет две операции, в которых сам выступает клиентом, а потом отсылает результаты собственно клиенту. Почему собственно клиент не мог эти два запроса сделать сам ? Или сформулирую иначе. Почему клиент сам не является для себя c.com ? Почему, если запросы к a.com и b.com будут делаться с клиента — это плохо, а вот если мы тут промежуточную конструкцию заведем — это будет хорошо ?

c.com выполняет две очень важную функцию: изолирует нашего пользователя от вывертов a.com и b.com.

PD>3. В продолжение п.2 Если функциональность клиента резко усложняется (например, уже не три строки отослать или получить, а десятки или сотни Кб) — зачем нужен лишний трафик ? Зачем c.com будет запрашивать сотню Кб с a.com, другую сотню с b.com и отылать все это клиенту, почему клиент не может сам эти Кб получить от a.com и b.com ?

Противоречит тому, что ты сам написал чуть ниже:

Поэтому всякие аргументы типа превращения c.com в универсальный построитель запросов неизвестно куда — приниматься не будут.

Уж либо тут сервер выполняет логические операции (вроде сопоставления данных о товаре и стоимости отправки), либо он выполняет ещё кучу неизвестно каких операций. В общем-то, когда нужно перекинуть сотни килобайт на клиента, можно взять, да перенаправить клиента непосредственно на источник данных (допустим, на a.com). По идее, нам безразлично, в каком виде они отображены, вот и отфутболим. А то, что нужно дополнительно обработать — обработаем у себя. Можно ещё и закэшировать что-нибудь...

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

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

У-у-у... Уже и две ОС появились. Ну, значит, будет две версии микроклиента с одним и тем же протоколом c_com_exchange_protocol.

PD>Короче — что тут полезного c.com делает ? Напоминаю, он придуман не мной, а моими оппонентами для решения именно той задачи, которую я поставил. Поэтому всякие аргументы типа превращения c.com в универсальный построитель запросов неизвестно куда — приниматься не будут.

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

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

ГВ>Да, a.com. Или b.com. Поменялся интерфейс, предоставляемый одним из этих серверов. Интерфейс в широком смысле этого слова: допустим, изменились соглашения о бинарном формате данных, доступных по обычному TCP/IP. Или поменялся порядок вызовов в каких-нибудь транзакциях. Или, что чаще всего — расширилась функциональность и теперь очень хочется эту самую расширившуюся функциональность дать нашим пользователям.

Вот это серьезно! Тут согласен. Но я же тебе хинт привел, а ты на него не обратил внимания.

PD>>Hint : если у тебя вместо Windows вдруг появился на машине Linux, то это значит, что у тебя действительно что-то поменялось всерьез. Но если ты проапгрейдил Windows 2000 до XP — я вообще-то могу считать, что у тебя все, что было, осталось, правда, кое-что добавилось.

При переходе от Windows 2000 к Windows XP изменились некоторые соглашения о бинарном формате данных (номера вызовов int 2e в ntdll.dll, например, да и в ядре самом не без изменений), расширилась функциональность и теперь очень хочется эту самую расширившуюся функциональность дать нашим пользователям.

И дали! Точно расширилась и все же дали!

dmz>Это не работает. JS из одного фрейма не получит доступ к данным другого фрейма. Нужен похаченный браузер — например, в виде плагина к мозилле (GreaseMonkey) — но мы полностью теряем универсальность тогда; с какой стати наши клиенты будут обязаны пользоваться мозиллой или ставить плагины?

Я наверное слегка сумбурно выразился, наверное. Я имел в виду именно похаченый браузер (в случае IE — просто захостеный в своём EXE-шном приложении MS HTML), но на стороне сервера. А именно в нём — открыть много-много фреймов, дабы чуть облегчить проблемы с масштабируемостью, чтобы был не один процесс на каждого клиента а один процесс на десяток-сотню клиентов.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

PD>Итак, ты согласился, что здесь будет некий API, то ли XML-RPC, то ли SOAP, то ли REST. Поэтому часть дискуссии, где предлагалось парсить HTML, будем считать отныне несущественной.
Ок.
PD>Суммирую все окончательно.

PD>Клиент делает запрос к c.com. c.com, зная некий API, предоставляемый a.com (например, XML — RPC), выполняет клиент-серверную операцию, выступая при этом в роли клиента. Получив данные от a.com, он их аннализирует, формирует новый запрос , теперь к b.com, где также выступает в роли клиента. Запросы и ответы идут в виде неких XML или иных пакетов. Получив ответ от b.com, он формирует страницу (теперь уж HTML) и шлет ее клиенту, начавшему операцию.

PD>Вроде все верно, надеюсь.

PD>Теперь у меня вопросы.

PD>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.
Вообще-то, HTTP — очень хороший базовый протокол для передачи пользовательских данных. Почему не TCP/IP?
Потому, что в TCP/IP придется с нуля решать очень большой ряд задач:
— аутентификация
— кэширование
— компрессия
— безопасность коммуникации
— большое количество negotiations, начиная от ожидаемого типа контента и заканчивая предпочтительным языком и культурой.
В HTTP/HTTPS всё это есть. В готовом к употреблению виде. Поэтому в последнее время очень немногие сервисы в интернете используют неизвестные науке протоколы поверх TCP/IP.

PD>2. Что полезного делает c.com вообще ? Он выступает в роли сервера по отношению к клиенту, и, получив от него запрос, выполняет две операции, в которых сам выступает клиентом, а потом отсылает результаты собственно клиенту. Почему собственно клиент не мог эти два запроса сделать сам ? Или сформулирую иначе. Почему клиент сам не является для себя c.com ? Почему, если запросы к a.com и b.com будут делаться с клиента — это плохо, а вот если мы тут промежуточную конструкцию заведем — это будет хорошо ?
Отличный вопрос. Потому, что собственно только он и имеет значение. Давай попробуем понять, в чем разница?
Итак, с.com — ровно 1 (один). А вот воображаемых "локальных клиентов" — столько, сколько пользователей. Очевидно, что задача maintenance для веб-приложения решается гораздо проще.
Как ты там дальше пишешь — "если функциональность клиента резко усложняется"... Если мы говорим о полноценном приложении, скажем windows executable, то его надо обновлять, для чего нужны административные права; надо рисковать выкачиванием трояна, потому что неизвестно, какого происхождения этот очередной апдейт, и так далее.

Ок, мы можем зайти с другого конца и получить клиентское приложение, которое очень легко в деплойменте. Самый простой (для пользователя) способ это сделать — перевести описанное мной приложение на AJAX и делать запросы к обоим сервисам с клиента. Но никаких преимуществ от этого ни конечные пользователи, ни сервисы не получат.
Кроме того, я так понял, что ты не имел в виду такое решение.
Зато с.com в предложенном мной виде позволяет также использовать себя как сервис: например, я могу сделать сервис elephantsondemand.com, который будет спрашивать у тебя только адрес, и обращаться к c.com для выяснения цены доставки слона.

PD>3. В продолжение п.2 Если функциональность клиента резко усложняется (например, уже не три строки отослать или получить, а десятки или сотни Кб) — зачем нужен лишний трафик ? Зачем c.com будет запрашивать сотню Кб с a.com, другую сотню с b.com и отылать все это клиенту, почему клиент не может сам эти Кб получить от a.com и b.com ?
Вот именно! Зачем клиенту, который сидит за дорогим и тонким каналом, все эти сотни Кб? c.com расположен в датацентре; у него трафик очень дешевый, и качество интернета примерно в десять раз лучше, чем ты можешь себе представить. Кроме всего прочего,
А клиенту мы отдадим маленькую компактную страничку, которая быстро доедет до его браузера.
PD>4. На клиенте доступны все средства, предоставляемые операционной системой клиента. Например, можно реагировать на нажатия некоторой клавиши, что в Windows и Linux делается не совсем одним и тем же способом

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

PD>>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.

ГВ>Про HTTP вспомнили, потому что разговор заведён про web-приложения. Что ж тут удивительного? Вспоминали и про бинарные форматы.

Нет, мой вопрос не в этом. Зачем он тут нужен ? Без него можно вообще обойтись ?

PD>>2. Что полезного делает c.com вообще ? Он выступает в роли сервера по отношению к клиенту, и, получив от него запрос, выполняет две операции, в которых сам выступает клиентом, а потом отсылает результаты собственно клиенту. Почему собственно клиент не мог эти два запроса сделать сам ? Или сформулирую иначе. Почему клиент сам не является для себя c.com ? Почему, если запросы к a.com и b.com будут делаться с клиента — это плохо, а вот если мы тут промежуточную конструкцию заведем — это будет хорошо ?

ГВ>c.com выполняет две очень важную функцию: изолирует нашего пользователя от вывертов a.com и b.com.

Заменяя при этом на необходимость знать выверты самого c.com. Он что, их лучше, умнее. что ли ? И не пользователя он изолирует, а клиентское приложение. Пользователь в любом варианте о a.com не узнает. Но это к слову.

PD>>3. В продолжение п.2 Если функциональность клиента резко усложняется (например, уже не три строки отослать или получить, а десятки или сотни Кб) — зачем нужен лишний трафик ? Зачем c.com будет запрашивать сотню Кб с a.com, другую сотню с b.com и отылать все это клиенту, почему клиент не может сам эти Кб получить от a.com и b.com ?

ГВ>Противоречит тому, что ты сам написал чуть ниже:

ГВ>

Поэтому всякие аргументы типа превращения c.com в универсальный построитель запросов неизвестно куда — приниматься не будут.

Согласен. Моя ошибка. Ладно, уберу насчет трафика. Но универсальный построитель не приму — я задачу предложил, мои оппоненты c.com для этой задачи предложили.

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

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

ГВ>У-у-у... Уже и две ОС появились. Ну, значит, будет две версии микроклиента с одним и тем же протоколом c_com_exchange_protocol.

Для тебя новость, что на разных клиентах различные ОС ?

Да, будут два микроклиента. Но для пользователя — один из них. Пока он не работает одновременно с Windows и Linux. А еще проще — он знает, что ему надо установить клиента. Для установки клиента надо из броузера зайти по такому-то URL, там либо спросят об ОС, либо автоматически ее определят, выдадут клиента и он установится. И что ?

PD>>Короче — что тут полезного c.com делает ? Напоминаю, он придуман не мной, а моими оппонентами для решения именно той задачи, которую я поставил. Поэтому всякие аргументы типа превращения c.com в универсальный построитель запросов неизвестно куда — приниматься не будут.

ГВ>Главное — он позволяет оперативно модифицировать логику обработки данных, приходящих с a.com и b.com.

И все же — почему код, позволяющий оперативно модифицировать логику обработки данных, приходящих с a.com и b.com, должен находиться на некоем физическом сервере c.com и не может находиться у меня дома ?

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

PD>Ничего себе аргумент ! А если будет так

PD>

PD><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
PD><html>
PD>    <head>
PD>        <title>Product</title>
PD>    </head>
PD>    <body>
PD>        Name 
PD>     <br>
PD>        Elephant
PD>     <br>
PD>        Vertical Size
PD>     <br>
PD>      120
PD>    </body>
PD></html>
PD>

var heightExpression = new Regex(@"(?<=Vertical Size\D+)\d+");

PD>А если сайт выдает страницу не на английском ? Как там по португальски "высота" ?

Павел, ты вправду тупишь, или просто меня пораздражать решил? Я тебе уже написал все-все комментарии про то, как я буду решать задачу в тысяче разных случаев.
Если сайт португальский — я напишу португальский регексп. К чему этот идиотизм весь? Вон я присылал тебе ссылку на реальную задачу — парни берут курс валюты с rbc.ru. Именно разбором HTML. Поэтому перестань страдать херней и проверять мои знания регекспов. Вот давай ты напишешь, как ты будешь парсить такой респонс в твоем клиенте.

>>Из прочтения инструкции по пользованию приложением a.com, которая там рядом неизбежно расположена,
PD>У сайтов всегда есть инструкции по их пользованию ? Что-то я не припомню на сайтах таких инструкций — хорошо еще , если карту сайта приведут. Мы ведь о парсинге HTML говорим вроде, так, не о XML-RPC или SOAP. Вот там, да, инструкция будет.
Павел, я позволю себе напомнить, что вымышленный тобой сервис a.com предназначен для людей. Это означает, что среднестатистический пользователь этого сервиса способен понять, где именно на странице расположен размер, и в чем он измеряется. Из инструкции и других источников. Я отличаюсь от среднестатистического пользователя тем, что умею делать view source и смотреть, откуда взялась эта цифра, и как ее выдрать из остальной разметки.

>>а также из других источников
PD>И какие же другие источники у тебя есть , когда ты получил эту страницу и ничего больше ?
Павел, ты вообще хоть раз в интернете был?
Вот страница: http://www.rbc.ru/ Сможешь на ней курс евро к рублю найти? Или никак?
>>, я заключаю, что это высота товара в дюймах.

PD>Которая в ходе такого анализа вполне может оказаться в действительности расстоянием от штаб-квартиры компании до Нью_Йорка.
Нет, не может. По условиям задачи, сервис a.com "возвращает его цену, габариты, вес и адрес отправителя".

... << RSDN@Home 1.2.0 alpha rev. 677>>

PD>Суммирую все окончательно.

PD>Клиент делает запрос к c.com. c.com, зная некий API, предоставляемый a.com (например, XML — RPC), выполняет клиент-серверную операцию, выступая при этом в роли клиента. Получив данные от a.com, он их аннализирует, формирует новый запрос , теперь к b.com, где также выступает в роли клиента. Запросы и ответы идут в виде неких XML или иных пакетов. Получив ответ от b.com, он формирует страницу (теперь уж HTML) и шлет ее клиенту, начавшему операцию.

PD>Вроде все верно, надеюсь.

PD>Теперь у меня вопросы.

PD>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.

Можно тогда вообще все протоколы общения выкинуть в топку, ведь все можно поверх TCP/IP делать. Открывать сокет, писать данные напрямую

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

.

Ключевой момент. Для веб приложения это нажатие будет обрабатываться абсолютно одинаковым способом и на Линуксе и на Винде, и на Symbian и на Android'е

PD>На c.com скорее всего, вообще говоря, об операционной системе клиента неизвестно, а если даже и известно, то толку от этого мало — не устроишь же эмуляцию ее возможностей ? Зачем эти проблемы ?

Зачем c.com'у знать об операционной системе клиента?

PD>Короче — что тут полезного c.com делает ?

Действительно, зачем нужен сайт типа Expedia? Ведь можно убить n-цать человеколет, чтобы сделать десктоп-приложение, работающее на всех операционных системах в мире, причем обладающее далеко нетривиальной логикой

c.com нужен по следующим причинам:
— унифицированый доступ к разрозненым сервисам
— в случае если эти сервисы изменятся, изменится интрфейс их взаимодействия, условия взаимодействия, адреса взаимодействия и т.п., то пользователь услугами c.com'а от этого полностью защищен
— c.com может иметь сложную, нетривиальную логику
— все это доступно на бОльшем количестве платформ, чем может себе позволить любое десктоп-приложение

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>Но я же тебе хинт привел, а ты на него не обратил внимания.

PD>>>Hint : если у тебя вместо Windows вдруг появился на машине Linux, то это значит, что у тебя действительно что-то поменялось всерьез. Но если ты проапгрейдил Windows 2000 до XP — я вообще-то могу считать, что у тебя все, что было, осталось, правда, кое-что добавилось.

PD>При переходе от Windows 2000 к Windows XP изменились некоторые соглашения о бинарном формате данных (номера вызовов int 2e в ntdll.dll, например, да и в ядре самом не без изменений), расширилась функциональность и теперь очень хочется эту самую расширившуюся функциональность дать нашим пользователям.

PD>И дали! Точно расширилась и все же дали!

Что-то ничего не понимаю, а домысливать не хочу. Кто дал? Кому дал? (Гусары, цыц!) Где установлены обсуждаемые машины? У пользователя? На каком-то из серверов a.com, b.com, c.com? Объясни, пожалуйста, что ты имел в виду?

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

PD>>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.
S>Вообще-то, HTTP — очень хороший базовый протокол для передачи пользовательских данных. Почему не TCP/IP?
S>Потому, что в TCP/IP придется с нуля решать очень большой ряд задач:
S>- аутентификация
S>- кэширование
S>- компрессия
S>- безопасность коммуникации
S>- большое количество negotiations, начиная от ожидаемого типа контента и заканчивая предпочтительным языком и культурой.
S>В HTTP/HTTPS всё это есть. В готовом к употреблению виде. Поэтому в последнее время очень немногие сервисы в интернете используют неизвестные науке протоколы поверх TCP/IP.

Не пойдет. Я не о существующей реализации, а о принципах построения говорю. Это все можно было без HTTP сделать или нет ? То, что это наработано, а поэтому легко употребить — не спорю. Но ведь мы идеологию обсуждаем, так ? Для идеологии наличие существующих возможностей не аргумент.

S>Отличный вопрос. Потому, что собственно только он и имеет значение. Давай попробуем понять, в чем разница?
S>Итак, с.com — ровно 1 (один). А вот воображаемых "локальных клиентов" — столько, сколько пользователей. Очевидно, что задача maintenance для веб-приложения решается гораздо проще.
S>Как ты там дальше пишешь — "если функциональность клиента резко усложняется"... Если мы говорим о полноценном приложении, скажем windows executable, то его надо обновлять, для чего нужны административные права; надо рисковать выкачиванием трояна, потому что неизвестно, какого происхождения этот очередной апдейт, и так далее.

Ну-ну, поехали. Трояна можно и без EXE подцепить, а при закачке новых EXE от Mozilla или (о ужас) Windows Update, который заменяет модули ОС, я что-то не боюсь этого. Нечего брать клиентов с подозрительных сайтов да и вообще туда ходить.

PD>>3. В продолжение п.2 Если функциональность клиента резко усложняется (например, уже не три строки отослать или получить, а десятки или сотни Кб) — зачем нужен лишний трафик ? Зачем c.com будет запрашивать сотню Кб с a.com, другую сотню с b.com и отылать все это клиенту, почему клиент не может сам эти Кб получить от a.com и b.com ?
S>Вот именно! Зачем клиенту, который сидит за дорогим и тонким каналом, все эти сотни Кб? c.com расположен в датацентре; у него трафик очень дешевый, и качество интернета примерно в десять раз лучше, чем ты можешь себе представить. Кроме всего прочего,
S>А клиенту мы отдадим маленькую компактную страничку, которая быстро доедет до его браузера.

Я имел в виду, что клиенту надо отдать эти сотни Кб с a.com и b.com

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

. На c.com скорее всего, вообще говоря, об операционной системе клиента неизвестно, а если даже и известно, то толку от этого мало — не устроишь же эмуляцию ее возможностей ? Зачем эти проблемы ?
S>Павел, пардон, а какие именно средства нужны для данной задачи? Где тут проблема? Для чего тебе потребовалась операционка?

Для данной — может, и нет. Но в общем случае — нужны.

PD>>Короче — что тут полезного c.com делает ?
S>Как что делает? Он находит цену доставки заданного товара по заданному адресу. С точки зрения конечного пользователя это — идеальное решение.
S>Прежде всего потому, что его
S>а) легко найти

Ну никак не легче, чем клиента, делающего то же самое.

S>б) легко использовать

То же самое.

S>в) легко повторно использовать

Абсолютно. Установив раз, больше никогда устанавливать не придется — пока новая версия не появится. Но и при появлении новой версии не обязательно. А появится новая версия — он устроит auto upgrade. Как FireFox делает , к примеру.

S>Теперь мы ждем твоего решения этой задачи — в подробностях, как ты просил, и с подписью. А потом попробуем объяснить, почему твое решение не заработает.

Хм, так я же его с самого начала привел.

http://www.rsdn.ru/forum/message/2899518.1.aspx

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

PD>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.
А зачем изобретать велосипед заново? Можно взять и воспользоваться HTTP в качестве протокола транспортного уровня. Иначе придётся реализовывать свой протокол транспортного уровня попутно с протоколом приложения. А так есть разделение между протоколами. HTTP — стандарт, который поддерживают все веб-сервера и прекрасно подходит для обмена данными между сервером и клиентом различного рода приложений. Реализация его есть в библиотеках всех популярных ЯП. Я бы удивился если бы какое-либо неспециализированное web-приложение стало нарочно игнорировать использование HTTP в наше время и реализовывало бы свой "уникальный" транспортный протокол.

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

WF>>Хе-хе. Вот как раз такой случай у меня. Просто вешаем на сервер c.com прокси для AJAX-запросов и всё

Ну то есть эта проблема тоже более чем решаема.

dmz>malev.com

dmz>Ценообразование сложное, логика формирования цен целиком на клиенте на джаваскрипте из массива данных. Никакая прокся не поможет.
dmz>Но есть и светлые стороны — клиентская логика у них столь сложна, что ее никто не может у них переписать уже много месяцев — и однажды написанный для
dmz>них парсер работает стабильнее всех остальных. Венгры, одно слово...

Вообзе-то парсить их нафиг не надо

Их данные есть в Amadeus/Galileo. Если мы пишм действительно большой и серьезный сервис, то заключается договор с одним из них и данные тянутся оттуда

В противном случае надо трогать за вымя oneworld на пердемет наличия АПИ

И только потом парсить.

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

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

PD>>>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.

ГВ>>Про HTTP вспомнили, потому что разговор заведён про web-приложения. Что ж тут удивительного? Вспоминали и про бинарные форматы.

PD>Нет, мой вопрос не в этом. Зачем он тут нужен ? Без него можно вообще обойтись ?

Ответ ниже.

ГВ>>c.com выполняет две очень важную функцию: изолирует нашего пользователя от вывертов a.com и b.com.

PD>Заменяя при этом на необходимость знать выверты самого c.com. Он что, их лучше, умнее. что ли ?

Ask?! У серверов a.com и b.com есть фатальный недостаток — они написаны не нами. Поэтому наш сервер быстрее, сильнее и превосходит их во всём. Вон, ни тот, ни другой не знают даже о существовании друг друга. Ламерьё!

PD>И не пользователя он изолирует, а клиентское приложение. Пользователь в любом варианте о a.com не узнает. Но это к слову.

Ты "к слову" подметил очень важный аспект, между прочим.

PD>Для тебя новость, что на разных клиентах различные ОС ?

PD>Да, будут два микроклиента. Но для пользователя — один из них. Пока он не работает одновременно с Windows и Linux. А еще проще — он знает, что ему надо установить клиента. Для установки клиента надо из броузера зайти по такому-то URL, там либо спросят об ОС, либо автоматически ее определят, выдадут клиента и он установится. И что ?

Вестимо, начнёт работать. Суть не в этом. Вопрос в том, как часто его придётся обновлять.

PD>>>Короче — что тут полезного c.com делает ? Напоминаю, он придуман не мной, а моими оппонентами для решения именно той задачи, которую я поставил. Поэтому всякие аргументы типа превращения c.com в универсальный построитель запросов неизвестно куда — приниматься не будут.

ГВ>>Главное — он позволяет оперативно модифицировать логику обработки данных, приходящих с a.com и b.com.

PD>И все же — почему код, позволяющий оперативно модифицировать логику обработки данных, приходящих с a.com и b.com, должен находиться на некоем физическом сервере c.com и не может находиться у меня дома ?

Йоу! Потому что обновить код в одном месте всегда проще и дешевле, чем обновить его в нескольких десятках (сотнях, тысячах...) мест даже при наличии полуавтоматической апдейтилки.

dmz>>Т.е. открывает a.com и b.com в браузере (браузерах), допустим в скрытых фреймах, работает с ними при помощи JS, имитируя действия клиента, потом джаваскриптом-же собирает данные из DOM, потом что-то с ними делает. С браузером этот трюк не выйдет, так как есть защита от XSS, но если сделать своего клиента, который будет использовать несколько инстансов браузера или похаченный браузер — то все будет работать.

PD>Ну ин так. Ты сумел исхитриться с помощью скрытых фрейсов или похаченного браузера. Я бы просто специализированное окно открыл (может, видимое, может нет, может, поток , а не окно)(может, и в процессе браузер, не важно это) и в нем все сделал. Как — детали, несущественно. Но скорее всего — просто шлем a.com запрос в виде некоего XML (к примеру), получаем от него ответ в виде XML и т.д. Пользователь ничего не видит. А результат — может быть, можно и в окне броузера показать, а можно в окне.

Чем это отличается от предложенного нами решения? Наше решение будет работать и на моем Sony Ericsson K750i, а вот дестоп-приложение на нем работать не будет

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

M>>Кто пришел к HTML? О HTML вообще никто ни разу не упомянул вообще. c.com вытягивает данные с b.com и a.com — где в этой вразе говорится о HTML? Про заполнение веб-форм и парсинг ответа совсем не мы говорили

PD>Да ты же пятью строчками выше. Или я тебя не понял ? Впрочем, это не важно, тема HTML вроде закрыта.

Я там написал — в крайнем случае

Но мы уже действительно дугое обсуждаем

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.

M>Можно тогда вообще все протоколы общения выкинуть в топку, ведь все можно поверх TCP/IP делать. Открывать сокет, писать данные напрямую

Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?

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

.

M>Ключевой момент. Для веб приложения это нажатие будет обрабатываться абсолютно одинаковым способом и на Линуксе и на Винде, и на Symbian и на Android'е

Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?

PD>>На c.com скорее всего, вообще говоря, об операционной системе клиента неизвестно, а если даже и известно, то толку от этого мало — не устроишь же эмуляцию ее возможностей ? Зачем эти проблемы ?

M>Зачем c.com'у знать об операционной системе клиента?

Так ведь на c.com фактически все приложение-то и оказалось. На клиенте только ввод да картинка. Как только что-то усложнится — понадобится знать, можно ли это вообще клиенту вернуть или у него получить.

M>Действительно, зачем нужен сайт типа Expedia? Ведь можно убить n-цать человеколет, чтобы сделать десктоп-приложение, работающее на всех операционных системах в мире, причем обладающее далеко нетривиальной логикой

Не аргумент, извини

M>c.com нужен по следующим причинам:
M>- унифицированый доступ к разрозненым сервисам
M>- в случае если эти сервисы изменятся, изменится интрфейс их взаимодействия, условия взаимодействия, адреса взаимодействия и т.п., то пользователь услугами c.com'а от этого полностью защищен
M>- c.com может иметь сложную, нетривиальную логику
M>- все это доступно на бОльшем количестве платформ, чем может себе позволить любое десктоп-приложение

Все замечательно, и все же — почему для этого c.com должен стоять в Калифорнии, а не у меня в квартире ?

M>Вообзе-то парсить их нафиг не надо

Питнадцать центов транзакция, сами заключайте. А парсер для большинства сайтов пишется и проверяется за час, только на малев пришлось убить два — три дня, и то не моих.
А как допишу эвристику , так вообще будет один парсер на 80% сайтов.

и цена — это не единственная проблема. В общем не надо думать что мы об этом не думали. Мы думали.

PD>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?

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

M>В противном случае надо трогать за вымя oneworld на пердемет наличия АПИ

За ссылку спасибо — посмотрел, потестил, посмеялся.

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

Приятно с тобой беседовать. Я серьезно

ГВ>>>Про HTTP вспомнили, потому что разговор заведён про web-приложения. Что ж тут удивительного? Вспоминали и про бинарные форматы.

PD>>Нет, мой вопрос не в этом. Зачем он тут нужен ? Без него можно вообще обойтись ?

ГВ>Ответ ниже.

Я что-то не нашел.

ГВ>>>c.com выполняет две очень важную функцию: изолирует нашего пользователя от вывертов a.com и b.com.

PD>>Заменяя при этом на необходимость знать выверты самого c.com. Он что, их лучше, умнее. что ли ?

ГВ>Ask?! У серверов a.com и b.com есть фатальный недостаток — они написаны не нами. Поэтому наш сервер быстрее, сильнее и превосходит их во всём. Вон, ни тот, ни другой не знают даже о существовании друг друга. Ламерьё!

Действительно. Помню, 5 лет назад разговаривал с разработчиком a.com. Он мне про x.com и y.com в точности те же аргументы приводил

PD>>Да, будут два микроклиента. Но для пользователя — один из них. Пока он не работает одновременно с Windows и Linux. А еще проще — он знает, что ему надо установить клиента. Для установки клиента надо из броузера зайти по такому-то URL, там либо спросят об ОС, либо автоматически ее определят, выдадут клиента и он установится. И что ?

ГВ>Вестимо, начнёт работать. Суть не в этом. Вопрос в том, как часто его придётся обновлять.

Не придется. Он сам обновится. Поставь себе Mozilla или FireFox и жди. Как только новая версия появится, предложат обновить. И Windows Update так же работает, только не всю ОС (слава богу

. а лишь кое-что заменяет. И я даже не знаю, что именно.

ГВ>Йоу! Потому что обновить код в одном месте всегда проще и дешевле, чем обновить его в нескольких десятках (сотнях, тысячах...) мест даже при наличии полуавтоматической апдейтилки.

А в чем, собственно, проще ?

Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д. При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.

M>>Можно тогда вообще все протоколы общения выкинуть в топку, ведь все можно поверх TCP/IP делать. Открывать сокет, писать данные напрямую

PD>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?

?????????????????????????

Где это XML разделяется знаком & ???????????

http://ru.wikipedia.org/wiki/HTTP

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т.д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

...

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
Стартовая строка (англ. Starting line) — определяет тип сообщения;
Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
Тело сообщения (англ. Message Body) — непосредственно данные сообщения.

POST
Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса.

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

.

M>>Ключевой момент. Для веб приложения это нажатие будет обрабатываться абсолютно одинаковым способом и на Линуксе и на Винде, и на Symbian и на Android'е

PD>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?

Какой low-level keyboard hook с помощью SetWindowsHookEx?????

onKeyPress в Яаскрипте уже отменили?
Работу с клавиатурой в Флэше уже отменили?

PD>>>На c.com скорее всего, вообще говоря, об операционной системе клиента неизвестно, а если даже и известно, то толку от этого мало — не устроишь же эмуляцию ее возможностей ? Зачем эти проблемы ?

M>>Зачем c.com'у знать об операционной системе клиента?

PD>Так ведь на c.com фактически все приложение-то и оказалось. На клиенте только ввод да картинка. Как только что-то усложнится — понадобится знать, можно ли это вообще клиенту вернуть или у него получить.

????????????????????????????7

О каком клиенте мы говорим?

Еще раз. Веб-приложение — это сраница плюс сервер. Одно изменяется соответственно другому. С какого перепугу вдруг на странице появятся новые формы ля введения данных, если на сервере для них не будет логики, их обрабатывающей?

M>>Действительно, зачем нужен сайт типа Expedia? Ведь можно убить n-цать человеколет, чтобы сделать десктоп-приложение, работающее на всех операционных системах в мире, причем обладающее далеко нетривиальной логикой

PD>Не аргумент, извини

Еще как аргумент. Сколько времени и денег потребуется, чтобы разработать десктоп приложение, работающее на:
Windows 2000
Windows XP
Windows Vista
Windows Mobile 5
Windows Mobile 6

всех дистрибутивах Линукса

MacOS X
MacOS X for iPhone

Symbian

Andorid

Qtopia
OpenMoko

и т.п.

А билет на expedia я смогу заказать и используя свой SE K750i + Opera Mini

M>>c.com нужен по следующим причинам:
M>>- унифицированый доступ к разрозненым сервисам
M>>- в случае если эти сервисы изменятся, изменится интрфейс их взаимодействия, условия взаимодействия, адреса взаимодействия и т.п., то пользователь услугами c.com'а от этого полностью защищен
M>>- c.com может иметь сложную, нетривиальную логику
M>>- все это доступно на бОльшем количестве платформ, чем может себе позволить любое десктоп-приложение

PD>Все замечательно, и все же — почему для этого c.com должен стоять в Калифорнии, а не у меня в квартире ?

О, в квартире можно поставить сервер, хранящий информацию терабайтами? 0_о

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

M>>Вообзе-то парсить их нафиг не надо

dmz>Питнадцать центов транзакция, сами заключайте. А парсер для большинства сайтов пишется и проверяется за час, только на малев пришлось убить два — три дня, и то не моих.
dmz>А как допишу эвристику , так вообще будет один парсер на 80% сайтов.

dmz>и цена — это не единственная проблема. В общем не надо думать что мы об этом не думали. Мы думали.

Не спорю

Вон, kayak.com за счет этого и живет, судя по всему, и ничего, довольно популярен

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?

F>HTTP — транспортный протокол.

Первый раз такое слыщу. Я как-то считал, что транспортным является TCP, а HTTP — протокол уровня приложения.

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

Он — не протокол, верно. Но что мешало сделать его протоколом на том же уровне, что и HTTP, FTP, SMTP... ?

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

PD>И все же — почему код, позволяющий оперативно модифицировать логику обработки данных, приходящих с a.com и b.com, должен находиться на некоем физическом сервере c.com и не может находиться у меня дома ?

Знаешь, а если с CORBA помудрить, то можно и на клиентскую машину затащить...

Уж гулять, так гулять!

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

PD>Не придется. Он сам обновится. Поставь себе Mozilla или FireFox и жди. Как только новая версия появится, предложат обновить. И Windows Update так же работает, только не всю ОС (слава богу

. а лишь кое-что заменяет. И я даже не знаю, что именно.

Серьезно? А у меня не обновляется, вот незадача. Более того, у меня прав-то даже нет его обновить! А запускается он, естественно, с моими правами.

PD>А в чем, собственно, проще ?

См. выше пример про FF. А вот http://google.com «у меня» постоянно обновляется — никаких проблем

Вон suggest не так давно появился.

PD>Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д.

Кому должен?

PD>При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.

Правда? Ты гарантируешь?

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

PD>Он — не протокол, верно. Но что мешало сделать его протоколом на том же уровне, что и HTTP, FTP, SMTP... ?

Что такое стек протоколов ясно? Понятно, зачем собирают стеки протоколов, а не начинают каждый протокол с описания сигналов в проводе и физических характеристик среды передачи данных?

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

PD>>[/code]
S>var heightExpression = new Regex(@"(?<=Vertical Size\D+)\d+");

PD>>А если сайт выдает страницу не на английском ? Как там по португальски "высота" ?

S>Павел, ты вправду тупишь, или просто меня пораздражать решил? Я тебе уже написал все-все комментарии про то, как я буду решать задачу в тысяче разных случаев.

Извини, но ты что-то дурочку валяешь. При чем тут замена Height на Vertical Size ? На каком основании ты решил, что употребление где-то в странице Vertical Size или Height дает тебе право ожидать, что дальше размер ? Кто тебе обещал, что завтра Height они на Vertical Size не поменяют ?

S>Если сайт португальский — я напишу португальский регексп. К чему этот идиотизм весь?

Вот именно. Парсим неизвестно что и утверждаем, что так можно надежные данные получить

>Вон я присылал тебе ссылку на реальную задачу — парни берут курс валюты с rbc.ru. Именно разбором HTML. Поэтому перестань страдать херней и проверять мои знания регекспов.

Нужны мне твои знания регэкспов как рыбке зонтик. Ты никак не можешь понять, что я тебе про то, что у тебя нет способа это вообще корректно определить, а ты мне строку в регэкспе меняешь!

>Вот давай ты напишешь, как ты будешь парсить такой респонс в твоем клиенте.

Я где-то обещал, что буду парсить HTML ? Ссылочку, пожалуйста!

>>>Из прочтения инструкции по пользованию приложением a.com, которая там рядом неизбежно расположена,
PD>>У сайтов всегда есть инструкции по их пользованию ? Что-то я не припомню на сайтах таких инструкций — хорошо еще , если карту сайта приведут. Мы ведь о парсинге HTML говорим вроде, так, не о XML-RPC или SOAP. Вот там, да, инструкция будет.
S>Павел, я позволю себе напомнить, что вымышленный тобой сервис a.com предназначен для людей. Это означает, что среднестатистический пользователь этого сервиса способен понять, где именно на странице расположен размер, и в чем он измеряется. Из инструкции и других источников. Я отличаюсь от среднестатистического пользователя тем, что умею делать view source и смотреть, откуда взялась эта цифра, и как ее выдрать из остальной разметки.

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

>>>а также из других источников
PD>>И какие же другие источники у тебя есть , когда ты получил эту страницу и ничего больше ?
S>Павел, ты вообще хоть раз в интернете был?

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

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

WF>Что такое стек протоколов ясно? Понятно, зачем собирают стеки протоколов, а не начинают каждый протокол с описания сигналов в проводе и физических характеристик среды передачи данных?

Ну это уж совсем несерьезно. При чем тут весь стек ? Кто предлагал реализовать XML протокол на базе физического уровня ?

HTTP на вершине стека, под ним TCP, а что ниже — сейчас тут ни при чем. Почему XML не может быть поверх TCP, зачем нужен HTTP в качестве промежуточного слоя ?

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

WF>Серьезно? А у меня не обновляется, вот незадача. Более того, у меня прав-то даже нет его обновить! А запускается он, естественно, с моими правами.

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

PD>>Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д.

WF>Кому должен?

Не кому должен, а должен. Точно так же, как сайт a.com со своими страницами должен отвечать по протоколу HTTP, а не черт знает что. Вот и сервис должен поддерживать свой АПИ.

PD>>При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.

WF>Правда? Ты гарантируешь?

Microsoft гарантирует одно из 3

Либо Win16 (или DOS) приложение будет работать
Либо оно (или ОС) выдаст корректную диагностику, почему оно не может работать.

Вариант "deprecated" не реализован.

Если знаешь иное — приведи.

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

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

А мне вот очень интересны технические подробности. А то решение тут описано на уровне ученика 9-го класса — "я сделаю програмку, в одном окошке пользователь введёт данные а в другом получит результат". Нельзя ли чуть подробнее — по каким протоколам будешь ходить к серверам и что будешь делать если эти протоколы поменяются (сайты нам не принадлежат, помнишь?), как будешь осуществлять авто-апдейт программы, как сделаешь её кросплатформенной. Хотя бы ключевые слова хотелось бы услышать. А то на данный момент мне сдаётся что ты здесь куче народу морочишь голову, заставляя подписываться под какими-то утверждениями и угрожая тузом в рукаве который ты вот-вот вытащишь и все поймут что веб-приложения — фуфло.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

PD>Ну это уж совсем несерьезно. При чем тут весь стек ? Кто предлагал реализовать XML протокол на базе физического уровня ?

HTTP на вершине стека, под ним TCP, а что ниже — сейчас тут ни при чем.

Кто сказал, что HTTP на вершине? Пойми, есть твои теоретические знания, а есть суровая реальность. Так вот, в реальности нет никакой 7-и уровневной модели OSI ISO, нет никакого HTTP на вершине стека.

Тебя, возможно, это шокирует, но HTTP протокол можно использовать, например, для туннелирования TCP/IP. Предлагаю подумать, как это трактуется с точки зрения 7-и уровневой модели. И такое встречается сплошь и рядом.

PD>Почему XML не может быть поверх TCP, зачем нужен HTTP в качестве промежуточного слоя ?

Вот именно потому же, почему мы не базируем его на физическом уровне. Потому что HTTP это очень удобная подложка для более высокоуровневых протоколов. Как уже заметили, сжатие, кэширование, шифрование, аутентикация.

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

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

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

WF>>Кому должен?

PD>Не кому должен, а должен. Точно так же, как сайт a.com со своими страницами должен отвечать по протоколу HTTP, а не черт знает что. Вот и сервис должен поддерживать свой АПИ.

А вот ничего он не должен. Он и по HTTP не должен отвечать, просто он тогда нафиг никому не нужен будет. Он по HTTP отвечает не потому, что это правильно, а потому что другого выбора нет

А вот менять свой API он может.

PD>Microsoft гарантирует одно из 3

PD>Либо Win16 (или DOS) приложение будет работать
PD>Либо оно (или ОС) выдаст корректную диагностику, почему оно не может работать.

PD>Вариант "deprecated" не реализован.

PD>Если знаешь иное — приведи.

А причем тут Microsoft? a.com написан не Microsoft, а какой-то конторой. Если она не будет заинтересована в таких гарантиях, то и давать их не будет. Зачем им это?

S>>Если сайт португальский — я напишу португальский регексп. К чему этот идиотизм весь?

PD>Вот именно. Парсим неизвестно что и утверждаем, что так можно надежные данные получить

Парсим мы известно что. Ответ на один и тот же запрос с северу более-менее стабилен. Можно написать монитор, который будет проверять,
что формат выдачи не менялся. Можно сделать интеллектуальный анализатор.

Точно так же, хозяева сервиса могут поменять формат XML. И что? О чем мы вообще говорим? Если по условию задачи a.com уже есть, и нормального API у него нет — то пользуемся чем есть. Если владельца a.com предоставили явное API — то они берут на себя обязательства его поддерживать. По большому счету, все равно, что возвращает из API — HTML, CSV, YAML, Plain Text, XML такой или сякой — главное что бы формат не менялся по десять раз на дню.

Какая-то сплошная демагогия. Альтернатива-то в чем? Придумать Единый Формат Описания Любых Данных и всех заставить им пользоваться?
Если что-то нельзя сделать автоматически на сервере — то это нельзя сделать автоматически и на клиенте. И клиент и сервер — программа. Какая разница где она работает?

Рисует вам интерфейс при помощи Win32 API или при помощи HTML в браузере?

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

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

PD>Нет. В первый раз вот здесь. Если ты решил дурочку валять — поищи другого оппонента, а я вынужден дискуссию с тобой прекратить.

Это недальновидно, потому что Синклер говорит по-существу, и его слова продиктованы практическим опытом, что заметно всем, кто в теме.
А вот что вы пытаетесь доказать, пока непонятно.

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

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

PD>>>1. Что тут делает HTTP ? Ведь фактически вы его используете в качестве своеобразного "транспортного" протокола для посылки этих самых XML и т.д. ? Вы же фактически новый протокол уровня приложения создали (XML API или иной)! Почему их нельзя послать просто средствами TCP/IP ? Только, пожалуйста, про брандмауэр говорить не надо.
S>>Вообще-то, HTTP — очень хороший базовый протокол для передачи пользовательских данных. Почему не TCP/IP?
S>>Потому, что в TCP/IP придется с нуля решать очень большой ряд задач:
S>>- аутентификация
S>>- кэширование
S>>- компрессия
S>>- безопасность коммуникации
S>>- большое количество negotiations, начиная от ожидаемого типа контента и заканчивая предпочтительным языком и культурой.
S>>В HTTP/HTTPS всё это есть. В готовом к употреблению виде. Поэтому в последнее время очень немногие сервисы в интернете используют неизвестные науке протоколы поверх TCP/IP.

PD>Не пойдет. Я не о существующей реализации, а о принципах построения говорю. Это все можно было без HTTP сделать или нет ?
Конечно можно.
PD> То, что это наработано, а поэтому легко употребить — не спорю. Но ведь мы идеологию обсуждаем, так ? Для идеологии наличие существующих возможностей не аргумент.
Ок, давайте тогда изобретем другой протокол поверх TCP/IP. Сделаем его stateless, для обеспечения масшитабируемости. Это идеологически важно.
Внедрим в него поддержку
— аутентификации
— кэщирования
— компрессии
— безопасности коммуникации
— перенаправления на другие источники
— обработки ошибок
— получения частичных результатов
— отправки запросов только в случае выполнения предусловий

И получим еще один HTTP.

PD>Ну-ну, поехали. Трояна можно и без EXE подцепить, а при закачке новых EXE от Mozilla или (о ужас) Windows Update, который заменяет модули ОС, я что-то не боюсь этого. Нечего брать клиентов с подозрительных сайтов да и вообще туда ходить.

PD>Я имел в виду, что клиенту надо отдать эти сотни Кб с a.com и b.com
Непонятно. Павел, ты поставил задачу — я ее решил. Просто поверь на слово, что если ты поставишь другую задачу — я ее тоже решу. Но давай не будем оценивать пригодность решения одной задачи для решения другой, ок?

PD>Для данной — может, и нет. Но в общем случае — нужны.
В общем случае решение может быть и другим.

PD>>>Короче — что тут полезного c.com делает ?
S>>Как что делает? Он находит цену доставки заданного товара по заданному адресу. С точки зрения конечного пользователя это — идеальное решение.
S>>Прежде всего потому, что его
S>>а) легко найти
PD>Ну никак не легче, чем клиента, делающего то же самое.
Ок, предположим, что одинаково.
S>>б) легко использовать
PD>То же самое.
НЕТ!!! Вот я нашел через гугл cтраничку c.com. В моем варианте я кликаю по ссылке — и через полсекунды передо мной "клиент", который я могу тут же попробовать.

В твоем варианте я кликаю по ссылке — и вижу диалог "скачать/запустить". Потом, через некоторое время (а ты в 400 байт своего умного клиента не уложишь), я получу инсталлятор на к себе машину. Теперь мне надо будет согласиться его установить. Для чего, как минимум, нужны административные права. Допустим, я его всё же рискнул и сумел поставить. Теперь сам по себе никуда не исчезнет, а продолжит отжирать место у меня на винте и в start menu. В то время как 400 байт исчезнут из кэша по стандартному LRU алгоритму, и мне нет нужды следить за сносом всякого мусора.
Для 98% пользователей вот эти "маленькие трудности" приведут к тому, что они нажмут back в браузере и поищут более дружелюбный сервис, реализованный в более прямой архитектуре.

S>>в) легко повторно использовать
PD>Абсолютно. Установив раз, больше никогда устанавливать не придется — пока новая версия не появится. Но и при появлении новой версии не обязательно. А появится новая версия — он устроит auto upgrade. Как FireFox делает , к примеру.
Отлично. Теперь ты начинаешь усложнять жизнь разработчику. В игру вступает сервер апдейтов и новая функциональность клиента, которую кто-то должен написать. Для веб приложений auto-update доступен бесплатно, из-за особенностей архитектуры.

Но я-то имел в виду, что пользователь может просто добавить в favorites (или на десктоп, или куда угодно) закладку, которая приведет его сразу к ответу на вопрос "сколько стоит привезти слона в Омск", даже если цены изменились. А может сохранить конкретный результат через Save As или через copy/paste для будущего сравнения.

S>>Теперь мы ждем твоего решения этой задачи — в подробностях, как ты просил, и с подписью. А потом попробуем объяснить, почему твое решение не заработает.

PD>Хм, так я же его с самого начала привел.
PD>http://www.rsdn.ru/forum/message/2899518.1.aspx
Нет, ты тут из меня все соки выжал, до подробных инструкций про то, как парсить семь разных видов результатов.
Будь любезен, опиши в деталях
— как именно твой клиент отправляет запрос на a.com
— как именно он получает ответ, как узнает, где в нем данные, а где мусор
— как он отправляет запрос на b.com
— как он получает от него данные
— что он делает, если обнаруживает, что сервис b.com не отвечает
— как он определяет наличие более новой версии себя же
— как и откуда он получает эту новую версию
— как он выполняет замену на лету кода, исполняющегося прямо сейчас

— сколько примерно времени займет разработка такого клиента, который бы успешно работал на windows
— сколько примерно времени займет разработка такого клиента, который бы cмог работать на мобильных платформах
— сколько примерно времени займет разработка такого клиента, который бы cмог работать на linux
— сколько примерно времени займет разработка такого клиента, который бы cмог работать на freebsd

На всякий случай я приведу пессимистичную оценку стоимости реализации своего клиента: 5 рабочих дней.
Из них 1 — на анализ a.com и b.com, 1 на выполнение собственно сервиса, 3 на украшение UI.

... << RSDN@Home 1.2.0 alpha rev. 677>>

HTTP на вершине стека, под ним TCP, а что ниже — сейчас тут ни при чем. Почему XML не может быть поверх TCP, зачем нужен HTTP в качестве промежуточного слоя ?
Потому, что XML — это не протокол. Это формат. С тем же успехом можно спрашивать "почему нельзя использовать UTF-8 вместо SMTP".
Поясняю на пальцах: протокол — это спецификация диалога.
Он описывает состояния диалога, сообщения между клиентом и сервером, уместные в каждом состоянии, а также правила перехода из состояния в состояние. Компрене ву?
XML ничего близкого не содержит. Он может использоваться в качестве формата сообщений того или иного прикладного протокола, построенного поверх TCP/IP.

... << RSDN@Home 1.2.0 alpha rev. 677>>

M>>В противном случае надо трогать за вымя oneworld на пердемет наличия АПИ

dmz>За ссылку спасибо — посмотрел, потестил, посмеялся.

Они кстати предлагают именно вариант павла — скачать какой-то клиент на очень ограниченное количество платформ. И пользоваться все равно удобнее expedia/kayak/веб-интерфейсом соответствующих компаний

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

>>Вот давай ты напишешь, как ты будешь парсить такой респонс в твоем клиенте.

PD>Я где-то обещал, что буду парсить HTML ? Ссылочку, пожалуйста!

Тогда как бует работать гипотетическое десктоп-приложение?

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

M>Они кстати предлагают именно вариант павла — скачать какой-то клиент на очень ограниченное количество платформ. И пользоваться все равно удобнее expedia/kayak/веб-интерфейсом соответствующих компаний

Ой. Нет, до этого не дошло, я просто поискал полеты из домодедово в берлин-тигель, посмеялся над результатом и ушел.

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

PD>>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?

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

M>Где это XML разделяется знаком & ???????????

Слушай, что с тобой ? Ты меня совсем понимать перестал. Я говорю, что XML передается сейчас с помощью HTTP, а для запроса нужна командная строка с этими &.

Вот такое можешь себе представить ?

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

При обращении к серверу a.com, поддерживающему XML протокол, надо ему передать некий "приветственный" XML. По порту YYY.
В ответ он , если жив, пришлет XML-ответ (аналог 200 OK)
После этого ему шлется произвольный XML на порт YYY. С запросом. Там не надо никаких страниц указывать. Там запрос на АПИ, который сервер a.com опубликовал. (Для получения этого АПИ надо ему послать XML запрос с единственной командой — дай АПИ)
Он его анализирует и определяет, что за запрос.
Формирует ответ, если может. Если не может, формирует ответ "ошибка". Ответ в XML — в любом случае.
Ответ посылается клиенту, он его принимает и анализирует. XPath, DOM и т.д.
Ответ используется клиентом как ему надо.

Где тут командная строка ? Где тут адрес страницы ? Где вообще страницы ? Где HTML ? (хотя. конечно, может быть, на некий запрос придет ответ в виде XML с CDATA, содержащем HTML). Где тут место HTTP ?

M>Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента.

Где в моей модели URI ? Кроме имени хоста, ничего не надо.

>Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т.д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

И на здоровье. Если надо в ответ прислать просто текст на китайском — шлите. Картинку в jpg — шлите. HTML — шлите. Но в ответе в виде элемента XML ответа.

M>Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

<skipped>

Спасибо за объяснения. См выше.

PD>>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?

M>Какой low-level keyboard hook с помощью SetWindowsHookEx?????

Обыкновенный. Твое web-приложение — это игра, динамическая. В Windows, допустим, можно поставить этот хук на клавиатуру, если надо.

M>onKeyPress в Яаскрипте уже отменили?

Батенька, ну не надо так. Фокус с приложения уйдет — ничего не получишь. А я хочу. чтобы мое приложение реагировало на нажатия клавиш, даже если оно не в фокусе.

M>Работу с клавиатурой в Флэше уже отменили?

Флэш — это ActiveX

. Исполняемый код, с вашего позволения. Встроившийся в IE, верно, но все же это EXE (DLL).

PD>>Так ведь на c.com фактически все приложение-то и оказалось. На клиенте только ввод да картинка. Как только что-то усложнится — понадобится знать, можно ли это вообще клиенту вернуть или у него получить.

M>????????????????????????????7

M>О каком клиенте мы говорим?

О web-клиенте. О том, что на нем игра сетевая, к примеру, а работать приходится через c.com.

M>Еще раз. Веб-приложение — это сраница плюс сервер. Одно изменяется соответственно другому. С какого перепугу вдруг на странице появятся новые формы ля введения данных, если на сервере для них не будет логики, их обрабатывающей?

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

M>Еще как аргумент. Сколько времени и денег потребуется, чтобы разработать десктоп приложение, работающее на:
M>Windows 2000
M>Windows XP
M>Windows Vista
M>Windows Mobile 5
M>Windows Mobile 6

M>всех дистрибутивах Линукса

M>MacOS X
M>MacOS X for iPhone

M>Symbian

M>Andorid

M>Qtopia
M>OpenMoko

M>и т.п.

Да разработаны же они! Та же Mozilla, к примеру. Денег — да. Времени — да. Но мы, кажется, вопрос все же про архитектуру и идеологию начали, нет ? Я и не утверждаю, что мое решение реально можно завтра пустить в ход. Все аргументы насчет денег и средств принимаю. Насчет сроков тоже.

Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.

M>О, в квартире можно поставить сервер, хранящий информацию терабайтами? 0_о

Ну не смеши ради бога. Что это такле на c.com в его нынешней версии есть, что требует терабайтов ?

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

PD>Приятно с тобой беседовать. Я серьезно

ГВ>>>>Про HTTP вспомнили, потому что разговор заведён про web-приложения. Что ж тут удивительного? Вспоминали и про бинарные форматы.
PD>>>Нет, мой вопрос не в этом. Зачем он тут нужен ? Без него можно вообще обойтись ?
ГВ>>Ответ ниже.
PD>Я что-то не нашел.

Главная часть ответа — это сопоставление количества потребных транзакций обновления.

ГВ>>>>c.com выполняет две очень важную функцию: изолирует нашего пользователя от вывертов a.com и b.com.
PD>>>Заменяя при этом на необходимость знать выверты самого c.com. Он что, их лучше, умнее. что ли ?
ГВ>>Ask?! У серверов a.com и b.com есть фатальный недостаток — они написаны не нами. Поэтому наш сервер быстрее, сильнее и превосходит их во всём. Вон, ни тот, ни другой не знают даже о существовании друг друга. Ламерьё!
PD>Действительно. Помню, 5 лет назад разговаривал с разработчиком a.com. Он мне про x.com и y.com в точности те же аргументы приводил

И правильно делал. x.com и y.com — это вообще древний хлам, про них в приличном обществе говорить уже не принято.

PD>>>Да, будут два микроклиента. Но для пользователя — один из них. Пока он не работает одновременно с Windows и Linux. А еще проще — он знает, что ему надо установить клиента. Для установки клиента надо из броузера зайти по такому-то URL, там либо спросят об ОС, либо автоматически ее определят, выдадут клиента и он установится. И что ?
ГВ>>Вестимо, начнёт работать. Суть не в этом. Вопрос в том, как часто его придётся обновлять.
PD>Не придется. Он сам обновится.

Сам... Как же! Юзер нажмёт на кнопку, и ещё раз, и ещё...

ГВ>>Йоу! Потому что обновить код в одном месте всегда проще и дешевле, чем обновить его в нескольких десятках (сотнях, тысячах...) мест даже при наличии полуавтоматической апдейтилки.
PD>А в чем, собственно, проще ?

В штуках транзакций обновления. В случае сервера такая транзакция одна. Меньше просто не придумаешь. И никаких возмущённых пользователей, которые не тем местом не туда нажали при получении критического обновления. А здесь, обрати внимание, ещё и особо пикантная ситуация: устроить нам весёлую жизнь с пользователями может руководство компаний, ответственных за a.com или b.com. За примерами таких ситуаций далеко ходить не надо. Когда там отгремела война ICQ и MSN? Тоже вот, оба юзали протоколы друг друга, одновременно модифицируя свои собственные, чтобы другой не смог.

PD>Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д.

Ну... Я так не играю. То у них ничего нет, то вдруг какой-то весьма хорошо поддерживаемый API появился. API — это как никак, Application programming interface. Если действительно API есть, то, между прочим, вариант с многочисленными браузерами в клиенте превращается в чистую фантастику. То есть получается, что ты клонил собеседников к тому, что сам же и опровергаешь путём дополнительных уточнений.

PD>При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.

Это очень существенное дополнительное условие. Спору нет, если у нас есть гарантия, что API a.com и b.com стабильны как скала, то может быть, можно и не заморачиваться с запуском своего узла только ради того, чтобы сопоставить продукт и цену доставки. Ну а если нет? Потому и предлагается решение, которое заведомо проще сопровождать, чем вагон клиентских приложений.

И кроме всего прочего, даже если API серверов стабилен, нельзя снять аргумент, касающийся того, что даже нашу собственную, то бишь, разработанную нами функциональность проще апгрейдить и фиксить на одном только сервере, а не уговаривая клиентов загрузить себе очередной апдейт.

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

PD>Извини, но ты что-то дурочку валяешь. При чем тут замена Height на Vertical Size ? На каком основании ты решил, что употребление где-то в странице Vertical Size или Height дает тебе право ожидать, что дальше размер ? Кто тебе обещал, что завтра Height они на Vertical Size не поменяют ?
Мне — никто. И тебе — никто. Дальше что?
Я отдаю себе отчет в ненадежности такого решения — но я с самого начала написал, что это крайний случай.

Когда они поменяют Height на Vertical Size, я получу нотификацию от своего единственного экземпляра сервиса c.com о том, что надо пойти и проверить, что у них там выдается.
Через максимум один день я поменяю регексп и всё заработает. А что будешь делать ты? Это же была твоя идея — делать всё тайком от сервисов a.com и b.com.

К счастью, в реальной жизни такие решения успешно работают. Именно благодаря тому, что приложения типа a.com и b.com писал не ты, а вменяемые разработчики. И они не стали выбирать "XML поверх TCP", который бы я никогда не распарсил.

>>Вон я присылал тебе ссылку на реальную задачу — парни берут курс валюты с rbc.ru. Именно разбором HTML. Поэтому перестань страдать херней и проверять мои знания регекспов.

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

PD>Слушай, что с тобой ? Ты меня совсем понимать перестал. Я говорю, что XML передается сейчас с помощью HTTP, а для запроса нужна командная строка с этими &.

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

PD>Вот такое можешь себе представить ?

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

[описание скипнуто]
Это не XML протокол. Это протокол ZZZ, использующий XML в качестве формата данных. SOAP, например.

PD>Где в моей модели URI ? Кроме имени хоста, ничего не надо.

Аналог URI в Вашей модели будет где-то внутри "произвольного XML с запросом". Поскольку, как ни крути, а сервису нужно сообщить, какое действие он должен выполнить или какой ресурс вернуть — а именно для этого в HTTP нужен URI.

PD>И на здоровье. Если надо в ответ прислать просто текст на китайском — шлите. Картинку в jpg — шлите. HTML — шлите. Но в ответе в виде элемента XML ответа.

И чем "элемент XML ответа" лучше, чем тело HTTP-ответа?

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

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

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

Так где все-таки подробное описание соответствующего клиентского приложения? С описанием методов получения и интерпретации данных с a.com и b.com?

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

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

Э... А это не твой ли десктоп собирался вынимать данные из того же a.com? Ты уж как-то определись сам: стабильный API у этих серверов или нет. А то говоришь, что он не стабильный — плохо; говоришь, что стабильный — тоже плохо. На худой конец, чётче сформулируй граничные условия, что ли...

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?
Ну если мы начали вдаряться в абстрактную философию, не обращая внимание на окружающую действительность, то давай поймем — зачем нам TCP/IP и XML? Почему не придумать какой-нибудь другой протокол и не гонять по нему данные в формате, скажем, ASN.43? Чем таким хорош TCP/IP?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

PD>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?

Игра, которой надо получать информацию о товарах и стоимость почтовых отправлений?

Странные у Вас развлечения, честное слово.

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

PD>При обращении к серверу a.com, поддерживающему XML протокол, надо ему передать некий "приветственный" XML. По порту YYY.
PD>В ответ он , если жив, пришлет XML-ответ (аналог 200 OK)
PD>После этого ему шлется произвольный XML на порт YYY. С запросом. Там не надо никаких страниц указывать. Там запрос на АПИ, который сервер a.com опубликовал. (Для получения этого АПИ надо ему послать XML запрос с единственной командой — дай АПИ)

PD>Где в моей модели URI ? Кроме имени хоста, ничего не надо.

Открывает порт. Допустим, 80-ый. Пишем туда данные. Допустим, пары ключ=значение. При желании — можем и XML записать. Сервер нам отвечает. Не в XML, правда, но может и в XML если надо.

Кроме имени хоста, ничего не надо.

Как же называется этот протокол? Может быть, HTTP? А может, REST? А может, SOAP? Или XMLRPC? Упс. Где-то я это уже видел. И в чем добавленная стоимость вашего решения? В чем ценность?

PD>Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.

Я понял, вы SOA изобрели. Через пять или шесть лет после Sun, IBM и Bea. Осталось понять, как заставить владельца a.com предоставлять API, что бы вы в своем клиенте захотите его сайт использовать.

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

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

PD>>>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?

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

M>>Где это XML разделяется знаком & ???????????

PD>Слушай, что с тобой ? Ты меня совсем понимать перестал. Я говорю, что XML передается сейчас с помощью HTTP, а для запроса нужна командная строка с этими &.

Совсем не обязательно. Это — детали реализации того или иного сервиса.

PD>Вот такое можешь себе представить ?
PD>Появился XML протокол. Порт YYY

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

PD>Где тут командная строка ? Где тут адрес страницы ? Где вообще страницы ? Где HTML ? (хотя. конечно, может быть, на некий запрос придет ответ в виде XML с CDATA, содержащем HTML). Где тут место HTTP ?

Сервер c.com может точно также посылать запросы другим серверам. Не обязательно по HTTP. Он точно так же может подсоединиться к серверу b.com по порту YYY, получить данные, обработать, отдать клиенту. В чем проблемы-то?

А если сервис b.com реализует десяток разных сервисов? Каждый навешиваем на свой порт? Или каждому передаем разные параметры при запросе? Чем это отличается от командной строки?

Более того, при POST-запросе никаких раделителей & может и не быть (чаще всего и нет), все происходит абсолютно аналогичным способом

M>>Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента.

PD>Где в моей модели URI ? Кроме имени хоста, ничего не надо.

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

>>Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т.д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

PD>И на здоровье. Если надо в ответ прислать просто текст на китайском — шлите. Картинку в jpg — шлите. HTML — шлите. Но в ответе в виде элемента XML ответа.

Почему обязательно XML?

M>>Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

PD><skipped>

PD>Спасибо за объяснения. См выше.

Вы бы почитали, что ли. Чем ваш самописный протокол отличается от стандартного HTTP-протокола?

PD>>>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?

M>>Какой low-level keyboard hook с помощью SetWindowsHookEx?????

PD>Обыкновенный. Твое web-приложение — это игра, динамическая. В Windows, допустим, можно поставить этот хук на клавиатуру, если надо.

Советую http://www.miniclip.com/ Как оно все работает под десятком платформ — уму не приложу

Или Doom на Яваскрипте: http://databay.invorbereitung.de/projekte/ay/js/

Еще раз: событие onKeyPress еще никто не отменял

M>>onKeyPress в Яаскрипте уже отменили?

PD>Батенька, ну не надо так. Фокус с приложения уйдет — ничего не получишь. А я хочу. чтобы мое приложение реагировало на нажатия клавиш, даже если оно не в фокусе.

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

M>>Работу с клавиатурой в Флэше уже отменили?

PD>Флэш — это ActiveX

. Исполняемый код, с вашего позволения. Встроившийся в IE, верно, но все же это EXE (DLL).

http://databay.invorbereitung.de/projekte/ay/js/

M>>Еще раз. Веб-приложение — это сраница плюс сервер. Одно изменяется соответственно другому. С какого перепугу вдруг на странице появятся новые формы ля введения данных, если на сервере для них не будет логики, их обрабатывающей?

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

Тогда мы говорим о десктоп-приложении, а не о веб-приложении

M>>Еще как аргумент. Сколько времени и денег потребуется, чтобы разработать десктоп приложение, работающее на:
M>>Windows 2000
M>>Windows XP
M>>Windows Vista
M>>Windows Mobile 5
M>>Windows Mobile 6

M>>всех дистрибутивах Линукса

M>>MacOS X
M>>MacOS X for iPhone

M>>Symbian

M>>Andorid

M>>Qtopia
M>>OpenMoko

M>>и т.п.

PD>Да разработаны же они! Та же Mozilla, к примеру.

И много таких приложений? И где мозилла на моем Сони-Эрикссоне?

PD>Денег — да. Времени — да. Но мы, кажется, вопрос все же про архитектуру и идеологию начали, нет ? Я и не утверждаю, что мое решение реально можно завтра пустить в ход. Все аргументы насчет денег и средств принимаю. Насчет сроков тоже.

PD>Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.

Обоснования кривизны архитектуры в этом топика так приведены и не были

M>>О, в квартире можно поставить сервер, хранящий информацию терабайтами? 0_о

PD>Ну не смеши ради бога. Что это такле на c.com в его нынешней версии есть, что требует терабайтов ?

http://www.paulgraham.com/carl.html

Терабайты я конечно загнул, но логика приложения будет очень сильно нетривиальной. Смысла ее держать на клиенте нет вообще. А если мы делаем тонкого клиента, то разницы между тонким клиентом практически не остается (за исключением того факта, что дестоп клиент заведомо сложно или невозможно портировать на такое же количество платформ)

... << RSDN@Home 1.2.0 alpha 3 rev. 968>>

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

PD>Да разработаны же они! Та же Mozilla, к примеру. Денег — да. Времени — да. Но мы, кажется, вопрос все же про архитектуру и идеологию начали, нет ? Я и не утверждаю, что мое решение реально можно завтра пустить в ход. Все аргументы насчет денег и средств принимаю. Насчет сроков тоже.

PD>Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.

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

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

WF>>Серьезно? А у меня не обновляется, вот незадача. Более того, у меня прав-то даже нет его обновить! А запускается он, естественно, с моими правами.

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

Где ты здесь теоретический спор нашёл? Доказательство положений "правильно" и "не правильно", путём приведения аргументов "надо", а также поиск ответа на вопрос "куды котимся?!" — это теоретизирование, что ли? Где теория?! Дайте мне теорию срочно!

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

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

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

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

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

Итак.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DesktopWeather.exe:1204 TCP divsoft:1684 i.imwx.com:http ESTABLISHED
DesktopWeather.exe:1204 TCP divsoft:1685 desktopfw.weather.com:http ESTABLISHED

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

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

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

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

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

Непонятен ровно один аспект. Зачем всё это? Какую выгоду это даёт? Чем это лучше существующей ситуации?

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

HB>Так где все-таки подробное описание соответствующего клиентского приложения? С описанием методов получения и интерпретации данных с a.com и b.com?

http://www.rsdn.ru/forum/message/2901424.1.aspx

Кое-что любопытное в твоём постинге, тем не менее, есть, но отпишусь позже. Где-то через полсуток.

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

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

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

ГВ>Э... А это не твой ли десктоп собирался вынимать данные из того же a.com?

Он. Впрочем, десктоп они или нет — зависит от того, как посмотреть. Приложение, в общем. Может, EXE, может, JAR, Может, еще что-то...

>Ты уж как-то определись сам: стабильный API у этих серверов или нет. А то говоришь, что он не стабильный — плохо; говоришь, что стабильный — тоже плохо. На худой конец, чётче сформулируй граничные условия, что ли...

http://www.rsdn.ru/forum/message/2901424.1.aspx

С моей точки зрения, витание в облаках начинается гораздо раньше, чем это указано в тексте.

Возражения:

1. Никаких ПРИНЦИПИАЛЬНЫХ отличий предполагаемого подхода от существующих решений на базе HTTP я не увидел. HTTP точно так же позволяет "ничего не знать о внутреннем устройстве сервера"; использовать строго заданный API; передавать описание API и т.д. и т.п. Так работают eBay, PayPal и много-много других сервисов.

2. Вы говорите об обсуждении архитектуры — и тут же начинаете описывать детали реализации, причем реализации неудачной. XML в качестве универсального формата не подходит хотя бы потому, что он исключительно текстовый. Tiff внутри XML — это будет не просто ужас, а ужас-ужас.

3. Приведенные Вами примеры никак не иллюстрируют Вашу точку зрения. Вы рассуждаете об универсальном протоколе и приводите в пример приложения, использующие протоколы крайне узкоспециализированные.

Много читал и не понял чем это вообще отличается от существующей ситуации в вебе. Тем что вместо 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>>

1. У меня уже сил нет. Отвечать всем сразу — никаких сил не хватит. Так что сегодня отвечать больше не буду.
2. У меня завтра занятия с утра до вечера, так что либо тоже не буду, либо поздно вечером.
3. В выходные я всегда вне Интернета.
4. Участвовать в этой дискуссии я мог лишь потому, что главный заказчик уехал в отпуск, а без него никто не решается сказать, что будем дальше делать. В понедельник он должен вернуться. Так что если в понедельник меня озадачат — смогу дать лишь короткие ответы.
5. Если кто-то хочет критиковать — критикуйте в ответ на родительское к этому сообщение. Отвечать на то, что будет написано в остальных ветвях, я не буду — по причине п.1-4.

Здравствуйте, 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>>

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

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

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

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

 // ну и т.д.

PD>5. Если кто-то хочет критиковать — критикуйте в ответ на родительское к этому сообщение. Отвечать на то, что будет написано в остальных ветвях, я не буду — по причине

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

Остальное даже обсуждать бессмысленно — все предложенные "новации" давно есть. Штука не в том, как поиметь универсальный протокол или API,
штука в том, как заставить владельцев пресловутых a.com его предоставить (ответ — никак, если они этого не хотят).

F>>HTTP — транспортный протокол.
PD>Первый раз такое слыщу. Я как-то считал, что транспортным является TCP, а HTTP — протокол уровня приложения.
Рискну заявить что такое классическое определение (TCP — транспортный, HTTP — протокол уровня приложения) является верным для приложения, в котором HTTP находится на вершине стека протоколов, то есть приложение, не использующее других протоколов поверх HTTP. К такому приложению относится простейший веб-клиент, не умеющий ничего более чем сделать запрос и получить его результаты, не знающий ничего о самих данных. Однако для веб-приложений, использующих к примеру XML сообщения для общения с сервером, HTTP становится фактически транспортным протоколом, а протоколом уровня приложения становится разработанный программистом веб-приложения сценарий общения клиента и сервера (в данном случае реализованный с помощью XML сообщений).

>>XML — язык разметки. Поэтому то и нет XML протокола поверх TCP/IP. Он вообще НЕ протокол.
PD>Он — не протокол, верно. Но что мешало сделать его протоколом на том же уровне, что и HTTP, FTP, SMTP... ?
Объясни мне на пальцах, каким образом понятие "язык разметки" (XML, CSS, HTML и т.д.) может быть как либо связано с понятием "протокол" (HTTP)???

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

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

Ни о чем не говорящий кусок кода, по-моему. Рассуждения о том, что "XML лучше HTTP", на мой взгляд, куда более показательны.

Немного подумав, решил дополнить.

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

Здравствуйте, Pavel Dvorkin

Парни! Вы о другом поспорьте: вот есть два сервиса a.com и b.com, они большие (ну, как гугль пусть

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

до тех пор пока хостер их пинками не выгонит за превышение квот. Все пользователи от такой любви убегут на бесплатный клиент Дворкина, который и у автора много времени не отнимает и работу свою работает. Вот. Теперь спорьте

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

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

После чего Синклер с Мамутом его продают. Задорого. Или наоборот, зарабатывают много денег, переносят c.com в свой собственный data center, а со временем покупают a и b.

Здравствуйте, 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!

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

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

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

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

Но тогда об идеальном решении можно говорить только в случае, если можно скрестить легкость развертывания веб-приложения с возможностями десктоп-приложения

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

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

H>Парни! Вы о другом поспорьте: вот есть два сервиса a.com и b.com, они большие (ну, как гугль пусть

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

Тем временем Дворкин будет все еще писать своего бесплатного клиента; потом он его напишет; сколько-то народи не осилят его скачать, сколько-то не осилят его запустить, потому что дотнет не той системы установлен или прав недостаточно; Потом a, b или c что-нибудь поменяют в своих интерфейсах, и клиент перестанет работать и надо будет срочно его обновить, с чем тоже справятся далеко не все. Пока написанный апдейт разойдется, a b или c опять что-то поменяют в интерфейсах, и все пойдет по новой. Пользователи тем временем забьют.

Здравствуйте, 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&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>>

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

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

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

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

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

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

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

Вообще-то не только это, но и это тоже.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

Главное, что это и сейчас можно сделать. Только, видимо, не только никому не нужно, но и вредно.

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

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

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

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

http://www.rsdn.ru/forum/message/27063.1.aspx

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

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

Здравствуйте, 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>

Угу, и в результате имеем тот же HTTP, только с более длинным заголовком и content-type обязательно text/xml.
Это если не вспоминать про сжатие и прочее, о чем Синклер уже не раз упоминал.

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

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

PD>http://www.rsdn.ru/forum/message/27063.1.aspx

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

Здравствуйте, 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". В ответ он ее и вернул.

Разумееется, в реальном запросе и на входе будет больше параметров, и результат будет посложнее.

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

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

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

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 с другой — любой из веб-серверов. Как эти вещи работают внутри — не должно иметь принципиального значения для разработки проекта. И тратить ценное время на реализацию этих вещей за деньги заказчика — неуместная роскошь.

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. никакого нового, несуществующего в природе протокола не потребовалось.

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

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

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

Приложение — некий код, выполняющийся на компьютере, устроит такое определение ? Этот код может быть получен на компьютер десятком способов (включая воровство, грабеж и обмен ворованным

, быть написан в виде исполняемого кода процессора, байт кода или интерпретироваться a la DOS Basic, обращаться к разным ресурсам Интернета за данными или другим кодом. Все.

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

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

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

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

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

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

Но как-то так получается, что веб-приложения делать быстрее, проще, дешевле поддерживать, быстрее распространять, да и пользователям часто оказывается удобно. Когда я могу один и тот-же почтовый ящик посмотреть и с телефона, и со станционарного компьютера, и с маленького eeepc 701, куда просто некуда ставить почтового клиента — это удобно. При этом я не теряю практически ничего. Зачем мне десктопное приложение для этого?

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

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

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

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

Не согласен.

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

Требование не принимается. И прав что либо требовать у тебя нет.

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

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

<skipped>

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

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

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

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

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

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

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

F>>Рискну заявить что такое классическое определение (TCP — транспортный, HTTP — протокол уровня приложения) является верным для приложения, в котором HTTP находится на вершине стека протоколов, то есть приложение, не использующее других протоколов поверх HTTP. К такому приложению относится простейший веб-клиент, не умеющий ничего более чем сделать запрос и получить его результаты, не знающий ничего о самих данных. Однако для веб-приложений, использующих к примеру XML сообщения для общения с сервером, HTTP становится фактически транспортным протоколом, а протоколом уровня приложения становится разработанный программистом веб-приложения сценарий общения клиента и сервера (в данном случае реализованный с помощью XML сообщений).
PD>+1. Именно так оно и есть.
То есть ты уже НЕ утверждаешь (как делал это раньше) что HTTP — протокол уровня приложения и следовательно ставить его в один рад с языком разметки XML бессмысленно?

F>>Объясни мне на пальцах, каким образом понятие "язык разметки" (XML, CSS, HTML и т.д.) может быть как либо связано с понятием "протокол" (HTTP)???

PD>Объясняю на пальцах.

PD>Протокол — это просто согласованный двумя участниками метод взаимодействия. Вот твой HTTP. Его понимают сервер и клиент HTTP, но не SMTP.

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

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 + протокол непосредственно уровня приложения. О вреде придумывания своего транспортного протокола для непоточной передачи данных — смотри моё предыдущее сообщение.

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

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

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

Но боюсь, что подобных вам оригиналов найдется немало, да и файрволлы просто зарубят левые соединения. А в корпоративном мире так вообще, все кроме HTTP(S) закрыто, и не только на уровне портов, а через проксю развязано, так что даже туннелировать ваш протокол через другие порты не получится.

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

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

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

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

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

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

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

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

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

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

Говорить, что все веб-приложения — отстой, вместо них должны бть только десктоп-приложения так же неверно, как и говорить обратное

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

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

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

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

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

Где тут место вашему протоколу?

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

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

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

На каком компьютере, под управлением какой операционной системы? Что буем делать с мобильными системами?

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

И в чем же заключается универсальность твоего способа структурирования запроса и ответа? В том что там есть элементы XML с атрибутами вместо plaintextового HTTP и нет "лишних" полей HTTP response? Сомнительное преимущество. Если бы заголовки HTTP в стандарте были прописаны в формате XML, суть протокола HTTP осталась бы та же самая.

Я когда-то был знаком с одним паровозным машинистом. Он водил тяжелые составы, и делал это очень хорошо. Получал премии и висел на Доске Почета. А вот самолетов он в жизни не видел, и , так уж сложилось, ничего о них не знал. И вот однажды я ему рассказал про самолет. Он крепко задумался , и через некоторое время привел мне целый набор аргументов, почему самолет — это плохо. Некоторые из аргументов я приведу

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

И т.д.

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

P.S. Просьба не принимать все сказанное всерьез.

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

PD>P.S. Просьба не принимать все сказанное всерьез.

Я думаю, уже не стоит об этом беспокоиться.

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

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

Если Вы собираетесь этот самолет строить самостоятельно, то лучше закажите паровоз.

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

M>На каком компьютере

на клиентском.

>под управлением какой операционной системы?

Установленной на нем.

>Что буем делать с мобильными системами?

А там ничего-таки нет ? Загрузи какой-нибудь tetris в свой мобильный телефон. Если он сумеет и ему будет разрешено выходить в Интернет через мобильную связь — вот тебе и это приложение. ОС, вообще-то, в классическом смысле, не обязательна.

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

PD>P.S. Просьба не принимать все сказанное всерьез.

Если его паровоз при этом может произвольно перемешщаться в пространстве со скоростью 850 км/ч, тогда к его аргументам имело бы смысл прислушаться.
Впрочем, паровоз еще умеет возить в десять раз больше людей и грузов, чем самолет.

Ваш самолет это умеет? Что-то принципально новое? Или он позволит что-то делать на порядок лучше, как самолет vs паровоз?
Где преимущества? Мы ждем.

Вот если бы вы обсуждали преимущества протокола для квантовых каналов связи vs XML over HTTP — нам бы крыть было бы нечем.
Так вот — преимущества?

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

Может, потом на что-то и отвечу, пока только маленькое замечание

S>Сочувствую вашим заказчикам. В случае если сервера и клиенты расположены в интернете. Да даже если это интранет — если бы вы выбрали HTTP, то получили бы надежную масштабируемую систему. А так вы занимаетесь просиранием средств на самописанные протоколы, которые будут страдать от всего того, что взрослые дяди вылечили примерно в 1996.

TECHNICAL SPECIFICATION October 2006 CEN/TS XXXX

CEN расшифровать или сам сможешь ?

Сейчас поискал в этом документе http. Встречается только в местах типа

xsi:schemaLocation="http:...

html встречается один раз, ссылка на документацию.

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

dmz>Ммм, я не буду вчитываться, давайте я предположу — смысл в том, что при наличии транзакции 1) клиенту передается некий токен 2) на сервере заводится сессия, которая болтается до таймаута или до коммита/роллбэка? В общем, так можно сделать поверх любого стейтлесс протокола, проблема в том, что это убийца масштабируемости и производительности.

Если честно, то я тоже не вчитывался

.
Я же написал, что конечно всё это можно повторить, вопрос только зачем нам ещё один велосипед?

Не выбрасывают же STL только потому, что самому можно сделать реализацию, которая будет в конкретном случае на 10% быстрее.

C>>Кроме того, SOAP не привязано к HTTP/HTTPS в отличии от REST. Главный смысл SOAP и Web Services в стандартизации общения между сервисами + наличие инструментов, которые позволяют автоматизировать часть работы.

dmz>Как правило, ничего кроме HTTP/HTTPS ничего не нужно, так как это единственное, что открыто.
Ну врядли привязку к HTTP/HTTPS можно назвать преимуществом. Есть тот же XMPP, который имеет преимущества для некоторых сценариев.

C>>Конечно всегда можно создать REST решение, превосходящее во всех отношениях SOAP и "WS-*", вопрос лишь во времени разработки и удобства использования.

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

, т.к. вообще нет понятия совместимости.

... << RSDN@Home 1.2.0 alpha rev. 693>>

dmz>>Да в общем-то, единственная проблема, которую я вижу в SOAP — регулярно встречающиеся проблемы с совместимостью различных реализаций.
C>В этом отношении REST конечно выигрывает

, т.к. вообще нет понятия совместимости.

Конечно. Реализаций HTTP клиентов и серверов много, и если не заработает с одной реализацией, то заработает с другой.
А вот что мне делать, если единственная имеющаяся для языка реализация SOAP клиента не работает с данным конкретным SOAP-сервером?

Это я пример из жизни привожу. При этом, SOAP сложный, за три дня на коленке клиента не переписать.

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

C>>А как REST решает поддержку транзакционности?
S>Никак. С точки зрения REST, 1 транзакция == 1 HTTP Request.
S>Чтобы обойти это ограничение, вводится дополнительный ресурс "транзакция", который за несколько запросов подготавливается, и затем одним запросом выполняется коммит.

А как же statelesness? Или под этим имеется в виду, что "транзакция" сохраняется в БД? Ну так и обычную ASP.NET сессию можно в БД хранить.

C>>Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?
S>Аутентификации — есть. Авторизации — нету, поскольку она за пределами протокола. Возврат информации об ошибке значительно более развит, чем в SOAP.

стандарты есть на возрат ошибок или как у каждого свои велосипеды?

C>>P.S. а что подразумевается под connectedness?
S>Возможность ссылаться из одного документа в другой.
S>REST веб-сервис позволяет до любого ресурса в рамках объектной дойти по ссылкам, начиная от service entry point.
S>Грубо говоря, в SOAP ты должен догадаться, что можно вызвать метод GetCustomers(), а потом передать один из ID полученных кастомеров в совершенно отдельный метод GetCustomerOrders(customerID).
S>А в REST ты получаешь, допустим, feed кастомеров, где каждая entry указывает на "страничку покупателя". Со странички покупателя на feed с его заказами ведет ссылка.
S>В итоге у тебя 2 способа получить доступ к некоторому ресурсу:
S>1. Сконструировать URL по заранее известным правилам
S>2. Проследовать до нужного ресурса, выбирая на каждом шагу нужную ссылку по определенным критериям

Честно говоря, слабо представляю смысл этого приимущества

. Или ты знаешь АПИ сервиса и тогда догадываться ни о чём не надо; или не знаешь — тогда проблемы возникнут в любом типе сервиса.
Может польза есть для автоматического построения UI для данного сервиса?

... << RSDN@Home 1.2.0 alpha rev. 693>>

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

dmz>Конечно. Реализаций HTTP клиентов и серверов много, и если не заработает с одной реализацией, то заработает с другой.
dmz>А вот что мне делать, если единственная имеющаяся для языка реализация SOAP клиента не работает с данным конкретным SOAP-сервером?

dmz>Это я пример из жизни привожу. При этом, SOAP сложный, за три дня на коленке клиента не переписать.

А весь и не надо в каждом конкретном случае. Неужели, любой другой XML формат всегда легче реализовать чем SOAP?

... << RSDN@Home 1.2.0 alpha rev. 693>>

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

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

M>>На каком компьютере

PD>на клиентском.

>>под управлением какой операционной системы?

PD>Установленной на нем.

>>Что буем делать с мобильными системами?

PD>А там ничего-таки нет ? Загрузи какой-нибудь tetris в свой мобильный телефон. Если он сумеет и ему будет разрешено выходить в Интернет через мобильную связь — вот тебе и это приложение. ОС, вообще-то, в классическом смысле, не обязательна.

Что-то я не вижу вагона приложений, которые без проблем работют хотя бы под 3-мя настольными и 1-2-мя мобильными операционными системами. А вдеь мы говорим о сложном приложении, работающим с нашим сервисом на любой платформе и предоставляющим одинаковые возможности под всеми платформами

Скайп в счет не берем, Скайп под Линуксом — это совсем не тот Скайп, что под Виндой
Мозиллу в счет не берем, на мобильных платформах ее нет
Остается только Опера. И то, разработчикам Оперы надо ставить памятник при жизни за такое достижение

И в это же время мое веб-приложение http://janus.dmitriid.com/ работает даже на таких платформах, о которых я ни сном ни духом

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

M>Говорить, что все веб-приложения — отстой, вместо них должны бть только десктоп-приложения так же неверно, как и говорить обратное

Ну я не знаю, как уже объяснять. Я ясно говорю — есть просто приложения, с той или иной степенью web (точнее, Интернет) компоненты. Мне опять в ответ — все веб-приложения — отстой, вместо них должны быть только десктоп-приложения ? Что за ерунда ?

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

F>Отлично. Ты усвоил понятие "протокол".

Думаю, что я его знал еще лет 20 назад, до появления Интернета в моей жизни

F>В своем новоиспечённом протоколе ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML + протокол непосредственно уровня приложения.

Маленький вопросик можно ? А если посылать по SMTP — это тоже будет request и response ? Или это свойства исключительно HTTP ? Или любой запрос есть request, а ответ — response , независимо от протокола ?

>О вреде придумывания своего транспортного протокола для непоточной передачи данных — смотри моё предыдущее сообщение.

О господи! Теперь уже предлагаемый мой протокол стал транспортным! Скоро, он, видимо, в твоей интерпретации физическим станет.

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

M>И в это же время мое веб-приложение http://janus.dmitriid.com/ работает даже на таких платформах, о которых я ни сном ни духом

Переносимость веб-приложений тоже не надо идиализировать. Попробуйте открыть новостной сайт (без специально адаптированной версии) открыть на среднестатистическом телефоне (а не на iPhone каком-нибудь) и расказать об удобстве использования

... << RSDN@Home 1.2.0 alpha rev. 693>>

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

M>И в это же время мое веб-приложение http://janus.dmitriid.com/ работает даже на таких платформах, о которых я ни сном ни духом

Все верно. Только задумайся еще — почему ? Ответ простой — потому что развитие в последние годв шло по этому пути. Если бы в свое время оно пошло по пути создания некоего промежуточного слоя между языком программирования и ОС, мы бы имели сейчас совсем другую картину. И приступая к разработке , ты бы знал, что оно должно будет работать под разными платформами. Но тебя бы это сильно не напрягало. Как не очень напрягает разработчиков сайтов под Java, которые сами по себе есть десктопные приложения, а работают под разными платформами. Все вопросы связанные с платформой, берет на себя Sun в своей VM.

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

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

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

M>>Говорить, что все веб-приложения — отстой, вместо них должны бть только десктоп-приложения так же неверно, как и говорить обратное

PD>Ну я не знаю, как уже объяснять. Я ясно говорю — есть просто приложения, с той или иной степенью web (точнее, Интернет) компоненты. Мне опять в ответ — все веб-приложения — отстой, вместо них должны быть только десктоп-приложения ? Что за ерунда ?

Не мы это начали

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

C>Переносимость веб-приложений тоже не надо идиализировать. Попробуйте открыть новостной сайт (без специально адаптированной версии) открыть на среднестатистическом телефоне (а не на iPhone каком-нибудь) и расказать об удобстве использования

Откройте для себя Opera Mini

На самом деле существует некоторый порог переносимости, но он гораздо ниже, чем у десктоп приложений

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>Откройте для себя Opera Mini

У самого опера на смартфоне стоит

M>На самом деле существует некоторый порог переносимости, но он гораздо ниже, чем у десктоп приложений

Согласен. Особенно это касается простых веб приложений.

... << RSDN@Home 1.2.0 alpha rev. 693>>

M>>И в это же время мое веб-приложение http://janus.dmitriid.com/ работает даже на таких платформах, о которых я ни сном ни духом

PD>Все верно. Только задумайся еще — почему ? Ответ простой — потому что развитие в последние годв шло по этому пути. Если бы в свое время оно пошло по пути создания некоего промежуточного слоя между языком программирования и ОС, мы бы имели сейчас совсем другую картину. И приступая к разработке , ты бы знал, что оно должно будет работать под разными платформами. Но тебя бы это сильно не напрягало. Как не очень напрягает разработчиков сайтов под Java, которые сами по себе есть десктопные приложения, а работают под разными платформами. Все вопросы связанные с платформой, берет на себя Sun в своей VM.

Свежо предание, да верится с трудом

Думаю, разработчики Java-приложений много могут рассказать о цене такой переносимости

А вот веб-приложения как раз такой прослойкой и являются

И я знаю, что оно работает под разными платформами

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

PD>>Все верно. Только задумайся еще — почему ? Ответ простой — потому что развитие в последние годв шло по этому пути. Если бы в свое время оно пошло по пути создания некоего промежуточного слоя между языком программирования и ОС, мы бы имели сейчас совсем другую картину. И приступая к разработке , ты бы знал, что оно должно будет работать под разными платформами. Но тебя бы это сильно не напрягало. Как не очень напрягает разработчиков сайтов под Java, которые сами по себе есть десктопные приложения, а работают под разными платформами. Все вопросы связанные с платформой, берет на себя Sun в своей VM.

M>Свежо предание, да верится с трудом

Думаю, разработчики Java-приложений много могут рассказать о цене такой переносимости

самые популярные десктоп-приложения на джаве — это среды разработки для джавы.

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

M>>На самом деле существует некоторый порог переносимости, но он гораздо ниже, чем у десктоп приложений

C>Согласен. Особенно это касается простых веб приложений.

...я бы уточнил. примитивных.

хочеца большего — как пример — качай java applet для gmail

M>>Свежо предание, да верится с трудом

Думаю, разработчики Java-приложений много могут рассказать о цене такой переносимости

dmz>самые популярные десктоп-приложения на джаве — это среды разработки для джавы.

Про мобильные приложения можно умолчать — полностью переносимых не так много, как хотелось бы

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Маленький вопросик можно ? А если посылать по SMTP — это тоже будет request и response?

Всегда приятно ответить начинающему на простой вопрос.
Нет, если посылать по SMTP, то все будет гораздо сложнее. Потому, что SMTP — stateful протокол, он подразумевает достаточно длинный диалог.
PD>Или это свойства исключительно HTTP ? Или любой запрос есть request, а ответ — response , независимо от протокола ?
В HTTP почти всегда диалог состоит ровно из одного запроса и одного ответа. В SMTP есть много request и много response.
>>О вреде придумывания своего транспортного протокола для непоточной передачи данных — смотри моё предыдущее сообщение.
PD>О господи! Теперь уже предлагаемый мой протокол стал транспортным! Скоро, он, видимо, в твоей интерпретации физическим станет.
Не кривляйся.

M>>>На самом деле существует некоторый порог переносимости, но он гораздо ниже, чем у десктоп приложений

C>>Согласен. Особенно это касается простых веб приложений.

S>...я бы уточнил. примитивных.

S>хочеца большего — как пример — качай java applet для gmail

Ээээ... Не понял. GMail доступен через веб-интерфейс и на тех же телефонах, например

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

dmz>Фигня какая-то. Сервер мы напишем на эрланге, и развернем на кластере из пятка машин. Когда клиентов станет столько, что кластер станет плохо, это будет значить, что нас совершенно немвеняемое количество клиентов, и Гугл с остальными уже стоят в очереди, что бы нас купить, а инвестор отвалил денег еще на пару сотен серверов для кластера.
Только эрланг я бы использовать не стал.
У нас его на одном проекте используют... раз в 2 месяца находят баги в рантайме... недавно его хваленая кластеризация глючила (подробности не выяснял) либы тоже сырые.
Так что жаба или .NET тут будут самое то. Они по крайней мере работают. А кластер всеравно придется очень хорошо продумывать ибо под большой нагрузкой любая автоматика расчитанная на некий общий случай в вакууме дохнет.

... << RSDN@Home 1.2.0 alpha rev. 745>>

dmz>>Фигня какая-то. Сервер мы напишем на эрланге, и развернем на кластере из пятка машин. Когда клиентов станет столько, что кластер станет плохо, это будет значить, что нас совершенно немвеняемое количество клиентов, и Гугл с остальными уже стоят в очереди, что бы нас купить, а инвестор отвалил денег еще на пару сотен серверов для кластера.
WH>Только эрланг я бы использовать не стал.
WH>У нас его на одном проекте используют... раз в 2 месяца находят баги в рантайме...

Пока мы сподобимся использовать его на вебе, там все косяки уже починят

Потом, у нас один проект на нем уже есть, и ощущения только положительные.

F>>В своем новоиспечённом протоколе ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML + протокол непосредственно уровня приложения.

PD>Маленький вопросик можно ? А если посылать по SMTP — это тоже будет request и response ? Или это свойства исключительно HTTP ? Или любой запрос есть request, а ответ — response , независимо от протокола ?
Ну и вопросы у тебя. Сам то понял что спросил? Request и response это английские слова, которые в русское языке звучат как "запрос" и "ответ" . Именно в этом контексте эти слова и следует понимать в моих сообщениях. Привязки к конкретным протоколам эти слова не имеют.

>>О вреде придумывания своего транспортного протокола для непоточной передачи данных — смотри моё предыдущее сообщение.
PD>О господи! Теперь уже предлагаемый мой протокол стал транспортным! Скоро, он, видимо, в твоей интерпретации физическим станет.
Давай будем отталкиваться от того что написано, а не от того что "станет в моей интерпретации".

. а лишь кое-что заменяет. И я даже не знаю, что именно.

Сижу на работе, отлыниваю от оной в рсдн — и вдруг бац — окно — "давай обновил фирефокс"! Я так, радостно, давай, только дочитаю и сразу обновим!
Прихожу домой, захожу почитать анекдоты — бац, давай обновим фирефокс! Вот, блин, вроде ж обновлял? А, то на работе было, ну давай, давай.
ну а за компом жены уже симптомы дежавю проявляются.
Хорошо хоть ноута у меня нет.

ЗЫ. Это не то,чтобы критика — действительно, ничего страшного, но реально у меня бывает по 3 обновления одной и той же программы и тогда приходит мысль, что схема веб-приложений, где пользователь и не знает что приложение может 20 раз поменялось — все же имеет свои плюсы не только с точки зрения разработчика

ЗЫ2
про точку зрения разработчика я и не говорю. Вот развернули мы веб-приложение .нет 2.0 на выделенном сервере у заказчика, ввели в эксплуатацию. Потом решили перейти на .нет 3.5. Согласовали по-быстрому с их ИТ, закатили фреймворк на этот сервер (там кроме нашей прилады ничего ценного не установлено вообще, потому и проблем в согласовании нет), накатили новую версию прилады вечерком и на следующий день пользователи запускают приложение и даже не знают, что там чего-то обновилось. А если бы мы захотели запросить накатить .нет 3.5 на каждый пользовательский компьютер в компании заказчика, то этот вопрос может согласовываться в ИТ, службе поддержки, и службе безопасности заказчика вплоть до выхода .нет 5.0....

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

В общем, продолжаю.

PD>Итак.

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

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

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

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

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

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

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

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

Ну, в общем, я всё понял (учитывая, что рядом ты высказался, что тебе нужен способ структурирования информации). Соответственно, главная проблема для вас — вовсе не выбор из этого странного ряда: XML/TCP/SOAP/HTTP/?/?/?. Самая сложная проблема — что описывать. Как структурируются данные? Как будет проводиться анализ API? Например, из того, что в каком-нибудь SOAP-интерфейсе описан метод, например, getOrderDetails, вовсе не следует, что система, наткнувшаяся на такой метод, с лёгкостью необычайной разберётся, скажем в том, где там в возвращаемых значениях номера позиций, а где артикулы. Совершенно нет никакой гарантии, что названия позиций будут содержать Name, а цены — Price.

То есть, задача выбора метода записи структурированных данных (XML/что-то ещё) не идёт ни в какое сравнение с задачей автоматического анализа описаний API. Зачастую это попросту невозможно — нужна тонкая и точная настройка как по названиям элементов, так и по их связям. Можно построить экспертную систему, но набивать её сведениями для резолюций придётся до бесконечности.

Я сейчас отнюдь не возражаю против того, чтобы сервер предоставлял описание доступных на нём сведений в том или ином виде. Проблема в том, что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.

Вот когда вы решите саму по себе задачу самоописаний, то есть попросту разберётесь — какой набор данных и когда должен или может передаваться, тогда отпадут и неоднозначности в оценке XML, Web и всех-всех-всех. Уверен, что можно будет даже и бинарным протоколом воспользоваться без особых неприятностей. Только так и никак иначе.

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

Паша, (извини за фамильярность) я когда это читал — просто рыдалЪ нервным смехом. И кто из нас тут юноша голубоглазый?

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

Конечно, может. При условии, что браузер знает несколько очень важных вещей:

1. Что в природе вообще существует некий эдакий штук под названием .tiff-формат, котрый обрабатывается вон той подпрограммой.
2. Что вроде бы, он должен быть картинкой.
3. Что если он встретит узел с названием <picture> (условно), у которого есть атрибут с названием "url", то этот самый "url" является не чем-нибудь, а именно URL в соответсвии с подобающими спецификациями (иначе это будет ошибка)
4. Что вычисленный шагом ранее URL содержит некоторый такой известный браузеру штукЪ под названием "расширение файла",
5. ...или, что в том же узле picture посредством другого атрибута указан "content/type", сведения из которого отменяют полученные на ш. 4,
6. Что загрузив некие невнятные данные с этого URL, опираясь на сведения о content/type можно эти данные затолкнуть вон той вот подпрограмме, которой нужно кроме того отдать всякие графические контексты и прочую требуху — нечто, наверное, нарисуется на экране пользователя.

Те же самые рассуждения справедливы, если узел XML содержит бинарные данные, например, в MIME-64 или хоть в Hexadecimal. Браузер всегда знает, что с какой буковкой нужно делать.

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

Внемли с разумением! Это никакое не ближайшее или отдалённое будущее, а ненаучная фантастика для околокомпьютерных журналов 80-х и жёлтой прессы 2000-х.

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

О реальности чего? Ты только что подмешал принципиально нерешаемую задачу к своим наблюдениям netstat. Ну ёлки зелёные...

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 тут или что-то иное — не знаю.

Моет быть он и комбинирует данные. Но skype очень-очень хорошо знает, какие данные и откуда он ждёт, а не так, мол — вот тебе данные, кувыркайся с ними как хошь. Иначе он был бы занят только перебором предположений: а что там ему припёрлось в очередном пакете?

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

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

Шиш. Если бы они не договорились заранее, то запросы протокола ни к чему бы не привели. Либо, если бы таковые запросы случились и к чему-то дельному привели, это означало бы, что и сервер и клиент располагают протколом о протоколах. Но располагают изначально, без всяких двусмысленностей.

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

Это уже детали в контексте того кошмара, о котором ты поведал.

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

Честно говоря, учить систему "понимать" XML обычно не нужно. Достаточно привинтить к ней что-то на базе SOAP, он для того и предназначен: для подцепляния legacy-систем. Дальше WSDL-описания можно использовать как карманную документацию, но и всё. Ровно так же (принципиально) работает позднее связывание LoadLibrary/GetProcAddress, например. С той лишь разницей, что список символов экспортируемых из DLL обычно не даёт никакой информации о типах параметров.

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

dmz>Веб-приложения разрабатывать дешевле. Hosted-веб приложения — еще дешевле. Экономия выходит во всём.

Очень опрометчивое утверждение, по крайней мере без указания того, что это за приложения. Вот у меня прямо сейчас открыты в студии два приложения, выполняющие абсолютно идентичные задачи, а именно RSDN@Home и rsdn.ru. На одну и ту же единицу функционала в первом случае усилий затрачивается сильно меньше (еще бы там код в свое время не превратили местами в каку

... <<RSDN@Home 1.2.0 alpha 4 rev. 1067 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Pavel Dvorkin,

(предыдущее сообщенеи ушло незаконченным, сорри модераторам за оверквотинг)

Собственно говоря, Павел, я, наконец-то понял, что меня изначально напрягло в этой дискуссии. Это были твои слова о какой-то абстрактной, отвязанной от всего "правильности" (а истина, она, как известно — всегда ... Какая?

). Такие рассуждения — опорная точка для поиска положений, которые случайно или преднамеренно перевёрнуты с ног на голову. Это могут быть посылки, где, например, перепутаны причины и следствия, где бесконечность объявлена конечной, что-то поделено на нуль или пустое множество полагается непустым. Достаточно таким макаром перевернуть одно, всего лишь одно рассуждение и вся цепочка остальных выводов летит в тартарары. Это справедливо и для математических выкладок, и для обычных, жизненных рассуждений.

Вот и здесь всё то же самое, что и всегда, по самому обычному сценарию. Ты руководствуешься какими-то невероятно огромными по масштабам соображениями о всеобщей описуемости всего, начисто упуская саму по себе техническую возможность такого описания (бесконечный цикл за 7 секунд, ага). Тут фокус в том, что никаких мощных, очень мощных и очень-очень мощных компьютеров никогда не хватит для решения такой задачи. Однако, таким образом ты теряешь опору для дальнейших рассуждений и начинаешь задаваться бессмысленными по существу вопросами. Потому такая длинная дискуссия, в которой стороны упорно не могут понять друг друга.

Касательно XML, то лучшее место для него — разметка естественного текста. Например, грамматические конструкции или семантические теги. Всё. На кой фиг его затащили в описание форматов данных — тайна сия необъятна есть. Могу предположить, что он просто оказался в нужном месте в нужное время. Но поскольку ниша эта и XML совсем не предназначены друг для друга, то чем стал XML? Правильно, он стал квазирелигией — это такая хрень, когда что-то непонятно куда приткнуть, и остаётся только верить, что это самое нечто — правильно. Верить при этом нужно всем сердцем и с чистым от дурных (а лучше — и ото всех остальных) мыслей разумом. Ибо. (На этом месте великие комбинаторы и провозвестники светлого будущего обычно замолкают и закатывают глаза) Ну а раз это — правильно, то и давай впендюривать этот самый XML куда надо, не надо и туда, где кажется, что не надо, но вдруг — надо? А потом можно поорать: "А! Это всё-таки получилось! Припаять XML к API! Ура!" Это, типа, символ веры такой.

Вот так, или примерно так.

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

PD>>Маленький вопросик можно ? А если посылать по SMTP — это тоже будет request и response ? Или это свойства исключительно HTTP ? Или любой запрос есть request, а ответ — response , независимо от протокола ?
F>Ну и вопросы у тебя. Сам то понял что спросил? Request и response это английские слова, которые в русское языке звучат как "запрос" и "ответ" . Именно в этом контексте эти слова и следует понимать в моих сообщениях. Привязки к конкретным протоколам эти слова не имеют.

Слава богу, что ты это понял. Теперь тебе остается понять, что ты написал

>ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML

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

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Маленький вопросик можно ? А если посылать по SMTP — это тоже будет request и response?
S>

Всегда приятно ответить начинающему на простой вопрос.

Всегда приятно получить от выдающегося специалиста ответ, даже если вопрос был задан не ему

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

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

Ответ от меня обязательно будет, но скорее всего не раньше понедельника. Это пишу на занятиях, сейчас пойду студенческую программу проверять.

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

Совсем забыл! Этот разговор с паровозным машинистом происходил давно. Потом много лет я с ним не встречался, а встретились осенью 2001 года, он уже на пенсии был. "Вот видишь, к чему твои самолеты приводят" — сказал он мне. "Еще ни одному террористу не удалось захватить паровоз, врезаться на нем в многоэтажное здание и повалить его!"

Здравствуйте, Curufinwe, Вы писали:
C>А как же statelesness? Или под этим имеется в виду, что "транзакция" сохраняется в БД? Ну так и обычную ASP.NET сессию можно в БД хранить.
При работе с транзакциями в общем случае без сохранения "промежуточного состояния" не обойтись. REST требует, чтобы промежуточные состояния тоже были валидными, и позволяет ограничить объем ресурсов, ассоциированных с незакоммиченной транзакцией.
C>стандарты есть на возрат ошибок или как у каждого свои велосипеды?
Конечно есть. См. RFC 2616, раздел 10 Status Code Definitions. Это значительно лучше, чем 4 fault code SOAP.

C>Честно говоря, слабо представляю смысл этого приимущества

. Или ты знаешь АПИ сервиса и тогда догадываться ни о чём не надо; или не знаешь — тогда проблемы возникнут в любом типе сервиса.
C>Может польза есть для автоматического построения UI для данного сервиса?

Автоматическое построение UI для сервиса — сказка для подростков. Преимущество в том, что сервис является самодокументирующим. Это сильно облегчает реализацию клиента, по сравнению с SOAP, WSDL которого совершенно нечитаем.

... << RSDN@Home 1.2.0 alpha rev. 677>>

dmz>>Веб-приложения разрабатывать дешевле. Hosted-веб приложения — еще дешевле. Экономия выходит во всём.

AVK>Очень опрометчивое утверждение, по крайней мере без указания того, что это за приложения. Вот у меня прямо сейчас открыты в студии два приложения, выполняющие абсолютно идентичные задачи, а именно RSDN@Home и rsdn.ru. На одну и ту же единицу функционала в первом случае усилий затрачивается сильно меньше (еще бы там код в свое время не превратили местами в каку

).

Ну вероятно, надо сделать какие-то оговорки относительно характера приложений; те приложения которые плохо вмещаются в возможности HTML/JS — это проблемы. Просто топик уже весь мозг разрушил, не до оговорок.

Но ведь думаю очевиден тот факт, что hosted веб-приложение должно работать только в одной среде — той, которую мы сами выбрали с самого начала; нам не надо заботиться о развертывании, мы можем использовать языки сколько угодно высокого уровня и любые библиотеки и средства, не заботясь о том, сколько место это все займет и отукда возьмется у пользователя. Есть еще много вещей, которым можно не придавать особенного значения при разработке web-приложений без существенного урона — версионность, например. Еще можно учесть легкость и скорость внесения исправлений, что существенно снижает требования к QA — все равно, если что, то никто не узнает и ничего не докажет

И т.п. согласитесь, тут есть существенные отличия от standalone приложений.

Может и прав. Эти шуточные аллегории опасны.

Я вот в июне прокатился по Европе и понял, что архитектура поезда гораздо удобнее для пользователя, чем у самолета.
Вот смотри: я доехал от Амстердама до Франкфурта за 4 часа.
При этом я уезжал из центра, и приехал в центр.
Предположим, что я попытался бы полететь на быстром-быстром самолете. Ок, сам полет там часа полтора. Процедура регистрации, предполетного досмотра и посадки занимает еще около 1.5 часов (и, кстати, весьма малоприятна). При этом я должен еще добраться из центра в аэропорт — а он на отшибе, даже в самых удобных европейских городах я не доберусь до аэропорта быстрее, чем за полчаса. Итого мы получили те же 4 часа, проведенные в суете и беготне. И это еще оптимистично — пробки могут сожрать и полтора часа на дорогу в аэропорт, к тому же мало кто рискует выезжать "впритык".

Это я к тому, что всё надо осматривать критически. Хотя в нашем с тобой споре про приложения ты занимаешь позицию твоего друга машиниста. Потому, что пытаешься защищать архитектуру, сложившуюся в до-веб эпоху, и игнорировать достижения прогресса. Мне смешно читать все эти "ах, если бы была такая среда, которая бы волшебно работала на всех машинах" — есть такая среда. Даже две: Javascript и Java.
При этом ты считаешь Java безусловно превосходящей технологией для клиента (забывая пояснить — почему), и почему-то не хочешь обращать внимание на то, что она так и не смогла заработать на десктопе. Вместо того, чтобы напрячь мозг и подумать, чем таким отличается Javascript, что приложения на нем превосходят Java по распространенности примерно как 10000:1, ты начинаешь придумывать всякие глупости типа "а вдруг веб-страница захочет сделать глобальный перехват клавиатуры".
Мне смешно читать все эти "ах, если бы был такой протокол удаленных вызовов, построенный на XML, и был язык его описания, и генератор клиентского и серверного кода по этому описанию". Потому, что вот есть SOAP, и за последние три года его наелись все по самое не хочу, и обнаружили в нем кучу недостатков. А ты вместо того, чтобы понять, за что критикуют SOAP, ты заново изобретаешь какой-то его вариант, который заведомо хуже продуман, зато тщательно копирует архитектурные просчеты SOAP. Зачем?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

Да все всё поняли:

От: dmz
Дата: 03.04.08 12:14

Альтернатива-то в чем? Придумать Единый Формат Описания Любых Данных и всех заставить им пользоваться?

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

Если речь идет о системе описания всего — то это очевидная химера, т.к. провалились даже попытки сделать стандартные описания каталогов
продукции для систем eCommerce, ввиду низкой востребованности. Впрочем, местами используется — стоит посмотреть BizTalk и что-то подобное.

Концепция системы узлов, обменивающихся сообщениями на XML-языке, со стандартизованным описанием бизнес-сущностей не нова, ее частные случаи даже
реализованы и применяются; непонятно какое это все отношение имеет к веб, по большому счету. По очень простому соображению — если мне нужны данные с
какого-то сайта в моей системе — я пойду их и возьму, а не буду дожидаться, пока владелец сайта прикрутит к нему какой-нибудь BizTalk, так как можно
никогда не дождаться.

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

M>>>>На самом деле существует некоторый порог переносимости, но он гораздо ниже, чем у десктоп приложений

C>>>Согласен. Особенно это касается простых веб приложений.

S>>...я бы уточнил. примитивных.

S>>хочеца большего — как пример — качай java applet для gmail

M>Ээээ... Не понял. GMail доступен через веб-интерфейс и на тех же телефонах, например

верно, доступен....инстоляхи с win 98 тоже доступны — однако ставят winXP. странно да?

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Маленький вопросик можно ? А если посылать по SMTP — это тоже будет request и response ? Или это свойства исключительно HTTP ? Или любой запрос есть request, а ответ — response , независимо от протокола ?
F>>Ну и вопросы у тебя. Сам то понял что спросил? Request и response это английские слова, которые в русское языке звучат как "запрос" и "ответ" . Именно в этом контексте эти слова и следует понимать в моих сообщениях. Привязки к конкретным протоколам эти слова не имеют.

PD>Слава богу, что ты это понял. Теперь тебе остается понять, что ты написал
Давай давай, обезьянничай, раз по существу сказать нечего. После вопроса "Или любой запрос есть request, а ответ — response , независимо от протокола ?" я могу только развести руками и признать этот случай клиническим.

>>ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML

PD>Ну а заодно помедитируй на тему о том, может ли язык разметки (как ты его называешь) XML быть в то же время протоколом запроса. При необходимости.
Неоходимости медитировать нет, ибо всё уже сказано. Кто не понял — сам виноват.

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

>>ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML

PD>Ну а заодно помедитируй на тему о том, может ли язык разметки (как ты его называешь) XML быть в то же время протоколом запроса. При необходимости.
Ну конечно же не может, сколько ни медитируй.
0. Потому, что нет такого понятия "протокол запроса":

No definitions were found for request protocol.

1. Потому, что сетевой протокол — это набор правил и процедур, которые описывают взаимодействие между сущностями в сети.
XML — не процедура, а его правила не описывают никакого взаимодействия.

XML можно использовать для:
1. Описания спецификации протокола. См. напр. WSDL, WADL, или ATOMPUB Service Document.
2. Формата представления сообщений в некотором сетевом протоколе. См. напр. SOAP, XML-RPC.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

S>Я вот в июне прокатился по Европе и понял, что архитектура поезда гораздо удобнее для пользователя, чем у самолета.
S>Вот смотри: я доехал от Амстердама до Франкфурта за 4 часа.
S>При этом я уезжал из центра, и приехал в центр.
S>Предположим, что я попытался бы полететь на быстром-быстром самолете. Ок, сам полет там часа полтора. Процедура регистрации, предполетного досмотра и посадки занимает еще около 1.5 часов (и, кстати, весьма малоприятна). При этом я должен еще добраться из центра в аэропорт — а он на отшибе, даже в самых удобных европейских городах я не доберусь до аэропорта быстрее, чем за полчаса. Итого мы получили те же 4 часа, проведенные в суете и беготне. И это еще оптимистично — пробки могут сожрать и полтора часа на дорогу в аэропорт, к тому же мало кто рискует выезжать "впритык".

Ха! Я это знал еще 20 лет назад. Полет Омск-Москва — 3 часа, время от момента выхода из квартиры в Омске до момента входа в квартиру в Москве — минимум 9.

Но поездом все же 44

S>При этом ты считаешь Java безусловно превосходящей технологией для клиента (забывая пояснить — почему)

Опять передержки. Я же писал сотню раз — EXE,JAR или не знаю что еще. Надоело.

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

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

PD>>Не придется. Он сам обновится. Поставь себе Mozilla или FireFox и жди. Как только новая версия появится, предложат обновить. И Windows Update так же работает, только не всю ОС (слава богу

. а лишь кое-что заменяет. И я даже не знаю, что именно.

F>Сижу на работе, отлыниваю от оной в рсдн — и вдруг бац — окно — "давай обновил фирефокс"! Я так, радостно, давай, только дочитаю и сразу обновим!
F>Прихожу домой, захожу почитать анекдоты — бац, давай обновим фирефокс! Вот, блин, вроде ж обновлял? А, то на работе было, ну давай, давай.
F>ну а за компом жены уже симптомы дежавю проявляются.
F>Хорошо хоть ноута у меня нет.

F>ЗЫ. Это не то,чтобы критика — действительно, ничего страшного, но реально у меня бывает по 3 обновления одной и той же программы и тогда приходит мысль, что схема веб-приложений, где пользователь и не знает что приложение может 20 раз поменялось — все же имеет свои плюсы не только с точки зрения разработчика

Options->Advanced->Update->automatically download and install update. "Пользователь и не знает что приложение может 20 раз поменялось"!

F>ЗЫ2
F>про точку зрения разработчика я и не говорю. Вот развернули мы веб-приложение .нет 2.0 на выделенном сервере у заказчика, ввели в эксплуатацию. Потом решили перейти на .нет 3.5. Согласовали по-быстрому с их ИТ, закатили фреймворк на этот сервер (там кроме нашей прилады ничего ценного не установлено вообще, потому и проблем в согласовании нет), накатили новую версию прилады вечерком и на следующий день пользователи запускают приложение и даже не знают, что там чего-то обновилось. А если бы мы захотели запросить накатить .нет 3.5 на каждый пользовательский компьютер в компании заказчика, то этот вопрос может согласовываться в ИТ, службе поддержки, и службе безопасности заказчика вплоть до выхода .нет 5.0....

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

dmz>>>Веб-приложения разрабатывать дешевле. Hosted-веб приложения — еще дешевле. Экономия выходит во всём.

AVK>>Очень опрометчивое утверждение, по крайней мере без указания того, что это за приложения. Вот у меня прямо сейчас открыты в студии два приложения, выполняющие абсолютно идентичные задачи, а именно RSDN@Home и rsdn.ru. На одну и ту же единицу функционала в первом случае усилий затрачивается сильно меньше (еще бы там код в свое время не превратили местами в каку

).

dmz>Ну вероятно, надо сделать какие-то оговорки относительно характера приложений; те приложения которые плохо вмещаются в возможности HTML/JS — это проблемы. Просто топик уже весь мозг разрушил, не до оговорок.

При любой сколь-либо серьезной обработке данных на клиенте js является узким местом из-за своего динамизма. Такое ощущение, что все иможет развалиться от одного чиха.

dmz>Но ведь думаю очевиден тот факт, что hosted веб-приложение должно работать только в одной среде — той, которую мы сами выбрали с самого начала; нам не надо заботиться о развертывании, мы можем использовать языки сколько угодно высокого уровня и любые библиотеки и средства, не заботясь о том, сколько место это все займет и отукда возьмется у пользователя. Есть еще много вещей, которым можно не придавать особенного значения при разработке web-приложений без существенного урона — версионность, например. Еще можно учесть легкость и скорость внесения исправлений, что существенно снижает требования к QA — все равно, если что, то никто не узнает и ничего не докажет

dmz>И т.п. согласитесь, тут есть существенные отличия от standalone приложений.

Все, о чем вы тут наговорили, решается с помощью java web start или апплетов, или там всяких silverlight или java fx (не считая установки jdk или .net runtime).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Есть десяток минут свободных, отвечу на один пункт. На остальное отвечать не буду — в общем, этого хватит, если захочешь — поймешь.

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

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

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

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

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

В общем — полное поражение. N : 0 в твою пользу.

А теперь основное.

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

Для тебя очевидно — просто не понимает человек сути, а высказывает какие-то странные идеи.

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

Маленькое отступление.

В 1985 году в СССР, о котором еще никто не знал, что жить ему 6 лет осталось, выходит одна книга по языку программирования. Некто Павел Дворкин, молодой (эх!

) эту книгу покупает ( я тогда все книги покупал, это было недорого и немного), листает и откладывает на полку, где ей предстоит, скорее всего, пролежать пару лет, а потом быть выброшенной.

Ну надо же! Нашлись два каких-то деятеля, новый язык придумали. Много таких языков уже было, мало кто о них помнит. Да еще с каким-то странным синтаксисом, да еще явно ориентированным на одну машину. В ИТ-сфере безраздельно царствует Фортран и царствию его конца не предвидится. На него миллионы и сотни миллионов потрачены. Компиляторы на каждой машине есть. Их крупнейшие фирмы делают (IBM, CDC, DEC). Конкуренты — ни одному (PL/1, Алгол-60, Алгол-68) ничего поколебать не удалось. Библиотеки огромны, вычислительные методы, графика, всякие задачи прикладной области. Знают его практически все.

А вы, что господа , предложили ? Что Вы показать можете ? Ничего у вас практически нет, кроме идеи. Да и идеи тоже нет, честно если сказать, ничего нового вы не придумали, все уже было, в PL/1, Алгол-68, Паскале. В общем, какое-то странное развлечение двух не от мира сего программистов. Зачем только наши издательства средства на перевод такой чепухи тратят?

И простояла эта книга у меня на полке хоть и не пять, но все же 3 года. Потом я ее с полки снял. Потом я ее от корки до корки прочел, и не раз. Потом оказалось, что этому гадкому утенку, обреченному на скорую гибель, суждено перевернуть мир вычислительной техники, свергнуть Фортран, занять его места, стать впоследствии родителем нескольких языков , которые все вместе и образуют большую часть современного мира ИТ.

О какой книге идет речь — думаю, все уже догадались. А я лишь могу пожалеть, что не обратил внимание на этот язык тогда, в 1985 году. Но в самом деле, на что он мне — компиляторов нет, ничего нет, а работодатель требует работу все же

Увы, времени уже тоже нет (сейчас), потому что надо на занятия идти. Но, поверь, этот пример не единственный.

Кстати, и на паровозы были сумасшедшие деньги потрачены в свое время. Надо было их совершенствовать до сих пор.

А еще в свое время природа потратила сумасшедшие средства на создание динозавров. Такие зубы, такой хвост, такая броня! Один, совсем ничтожный недостаток — холоднокровные, пока не нагреются на солнце — вялые очень. И тут какие-то несчастные твари появилсь, ростом с мышь, яйца откладывать не умеют, брони нет, зубов нет, чешуи нет, размеры — динозавр наступит и не заметит.

На этом и закончу.

LP>При любой сколь-либо серьезной обработке данных на клиенте js является узким местом из-за своего динамизма. Такое ощущение, что все иможет развалиться от одного чиха.

Это вы не умеет его готовить

На тему статика vs. динамика тут уже столько копий сломано, уууу

Серьезным минусом JS являтся его слабая типизированность — это да

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

M>>>>>На самом деле существует некоторый порог переносимости, но он гораздо ниже, чем у десктоп приложений

C>>>>Согласен. Особенно это касается простых веб приложений.

S>>>...я бы уточнил. примитивных.

S>>>хочеца большего — как пример — качай java applet для gmail

M>>Ээээ... Не понял. GMail доступен через веб-интерфейс и на тех же телефонах, например

S>верно, доступен....инстоляхи с win 98 тоже доступны — однако ставят winXP. странно да?

Не поял, причем тут это

Вернее так. Надо сначала определить понятие "веб-приложение"

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

Не раз упомниаемая здесь expedia — это тоже веб приложение, причем очень серьезное и сложное

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Опять передержки. Я же писал сотню раз — EXE,JAR или не знаю что еще.
В это "не знаю что еще" входит джаваскрипт, выполняющийся в контексте веб-страницы? Или это непременно должно быть приложение с самостоятельным окном?

... << RSDN@Home 1.2.0 alpha rev. 677>>

В 90-е годы была такая замечательная социальная реклама, с ручной крысой в женском общежитии — "ставьте перед собой реальные цели". Приятно наверное ставить себя на одну планку с Керниганом и Ритчи, но всё же ИМХО стОит оглянуться и посмотреть по сторонам — может, есть возможность вложить силы в куда как менее авантюрное предприятие?

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

PD>Суть твоих аргументов — есть наработанная технология, на нее миллионы и миллиарды потрачены, а тут кто-то выходит и говорит — неправильно это все, давайте будем совсем иначе строить.
Нет. Кто-то выходит и говорит "давайте вернемся назад в 1988 год и сделаем вид, что веб-приложений нету, потому что я их не понимаю".
PD>При этом в деталях решение не предлагает, в подробности входить порой не хочет, ему на важные моменты показывают — он и внимания не обращает и т.д.
PD>Для тебя очевидно — просто не понимает человек сути, а высказывает какие-то странные идеи.
Павел, проблема — в том, что никаких идей ты не высказываешь. Я тебе в ндцатый раз повторяю: эта "новая" архитектура была актуальна 20 лет назад, и устарела 10 лет назад. Все необходимые технологии для нее — вот они, на месте. Но они не работают! Сейчас не-веб приложений в интернете считанные единицы. А ты огульно называешь веб-приложения "негодными", не понимая, что они-то как раз годные. А твои предложения потребовать чтобы каждый, кто хочет узнать, сколько стоит билет из A в B, ставил себе "EXE, JAR, не знаю что", несовместимы с реальностью.

Ты мне напоминаешь Тео Мандела: тоже осененный учеными степенями чувак. Но в 2008 году читать вещи типа "Ах, вот если бы существовал графический интерфейс пользователя, во было бы классно", как-то смешно. Потому что таки да, уже двадцать лет как все мечты дедушки были реализованы, попробованы и развиты. Появилось целое следующее поколение GUI. А дедушка всё рассказывает про то, какие были бы классные листвью.

PD>Я тебя существенно постарше, и почти все развитие ВТ прошло на моих глазах (только самое начало не захватил). И поэтому для меня твои аргументы хоть и существенны, но не окончательны. Потому что я знаю — такое уже было. И знаю, чем закончилось.
Что именно уже было?

PD>Ну надо же! Нашлись два каких-то деятеля, новый язык придумали. Много таких языков уже было, мало кто о них помнит. Да еще с каким-то странным синтаксисом, да еще явно ориентированным на одну машину. В ИТ-сфере безраздельно царствует Фортран и царствию его конца не предвидится. На него миллионы и сотни миллионов потрачены. Компиляторы на каждой машине есть. Их крупнейшие фирмы делают (IBM, CDC, DEC). Конкуренты — ни одному (PL/1, Алгол-60, Алгол-68) ничего поколебать не удалось. Библиотеки огромны, вычислительные методы, графика, всякие задачи прикладной области. Знают его практически все.

PD>А вы, что господа , предложили ? Что Вы показать можете ? Ничего у вас практически нет, кроме идеи. Да и идеи тоже нет, честно если сказать, ничего нового вы не придумали, все уже было, в PL/1, Алгол-68, Паскале. В общем, какое-то странное развлечение двух не от мира сего программистов. Зачем только наши издательства средства на перевод такой чепухи тратят?

PD>И простояла эта книга у меня на полке хоть и не пять, но все же 3 года. Потом я ее с полки снял. Потом я ее от корки до корки прочел, и не раз. Потом оказалось, что этому гадкому утенку, обреченному на скорую гибель, суждено перевернуть мир вычислительной техники, свергнуть Фортран, занять его места, стать впоследствии родителем нескольких языков , которые все вместе и образуют большую часть современного мира ИТ.
Это ты про какой язык, интересно? Я че-то не понял. Бэйсик что ли?

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

PD>Увы, времени уже тоже нет (сейчас), потому что надо на занятия идти. Но, поверь, этот пример не единственный.
PD>Кстати, и на паровозы были сумасшедшие деньги потрачены в свое время. Надо было их совершенствовать до сих пор.
Павел, паровоз — это как раз EXE клиент, который общается с сервером по проприетарному RPC-style протоколу. На корбу потрачены были совершенно безумные деньги. И где она теперь? Покажи мне миллионы публичных корба-сервисов в интернете.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

L>В 90-е годы была такая замечательная социальная реклама, с ручной крысой в женском общежитии — "ставьте перед собой реальные цели". Приятно наверное ставить себя на одну планку с Керниганом и Ритчи,
Не может такого быть. К 1985 году про С никак нельзя было сказать, что он ориентирован на одну машину, и что компилятора нет.
Либо у Павла плохо с памятью, либо он намекает на кого-то еще.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

L>В 90-е годы была такая замечательная социальная реклама, с ручной крысой в женском общежитии — "ставьте перед собой реальные цели". Приятно наверное ставить себя на одну планку с Керниганом и Ритчи, но всё же ИМХО стОит оглянуться и посмотреть по сторонам — может, есть возможность вложить силы в куда как менее авантюрное предприятие?

Что вы все так нервничаете, что вас так раздражает ? Мы же все-таки в форуме по философии программирования, а не в форуме о юзеровском интерфейсе, не так ли ? Вам сильно не нравится, что ставится под некоторое сомнение тот подход, который вы используете ? А он что, священная корова ?

Поверь, свои деньги я зарабатываю, и отнюдь не этим, хотя и связанным с этой моделью.

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

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

L>>В 90-е годы была такая замечательная социальная реклама, с ручной крысой в женском общежитии — "ставьте перед собой реальные цели". Приятно наверное ставить себя на одну планку с Керниганом и Ритчи,
S>Не может такого быть. К 1985 году про С никак нельзя было сказать, что он ориентирован на одну машину, и что компилятора нет.

Hint : дело было в СССР в 1985 г, и Интернета не было и в помине, так что о том, что делается в мире, мы знали очень плохо. Unix'ом развлекались немногие. Что касается ориентации — почитай про автоинкрементный режим у PDP/11.

PD>Что вы все так нервничаете,
Да упаси Боже, я абсолютно спокоен

PD>что вас так раздражает ?
А раздражает — масштабность подхода. Ну как Шариков, ей Богу — несогласен с обоими, взять всё да разделить. Вместо того чтобы посмотреть по сторонам и увидеть что люди наработали в этом направлении за последний десяток лет — берёшься утверждать дескать "всё это фуфло, не так надо было делать, вот я бы сделал не так, ещё не знаю как — но не так, а те кто против — так Коперника и Галлилея тоже гнобили".

... << RSDN@Home 1.2.0 alpha rev. 717>>

PD>Что вы все так нервничаете, что вас так раздражает ?

Весна, авитаминоз, шизофрения

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>Это вы не умеет его готовить

На тему статика vs. динамика тут уже столько копий сломано, уууу

Серьезным минусом JS являтся его слабая типизированность — это да

Есть ещё один недостаток — тормознутость. Где-то была демка на Silverlight 1.1 шахмат. Там можно было заставить играть JS движок против .NET движка. Скорость просчёта ходов отличалась на порядки. Хотя конечно для простых веб приложений скорость работы клиентского кода не очень важна.

... << RSDN@Home 1.2.0 alpha rev. 693>>

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

PD>Hint : дело было в СССР в 1985 г, и Интернета не было и в помине, так что о том, что делается в мире, мы знали очень плохо. Unix'ом развлекались немногие. Что касается ориентации — почитай про автоинкрементный режим у PDP/11.

А, то есть ты всё-таки про запоздалую любовь к C? Нда уж. "Малоизвестный язык... только идея"...
Читать хотя бы http://www-db-out.research.bell-labs.com/cm/cs/who/dmr/chist.html до просветления. Там написано, какие именно конкурентные преимущества были у языка С, и которые обеспечили ему успех. Можешь, к примеру, поинтересоваться, как выглядели строковые константы в "безраздельно царствующем" на момент разработки C Фортране-66.

Так что параллелей с твоим случаем я не вижу.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

C>>Может польза есть для автоматического построения UI для данного сервиса?

S>Автоматическое построение UI для сервиса — сказка для подростков. Преимущество в том, что сервис является самодокументирующим. Это сильно облегчает реализацию клиента, по сравнению с SOAP, WSDL которого совершенно нечитаем.

Кто-то пытается читать WSDL кроме генератора проксей?

А человека обычно читает документацию. Строить взаимодействие с сервисом у которого нет документации, а только "самодокументирующиеся" примеры request/response — это экстрим какой-то.

P.S. может есть ссылка на статью (не книгу) где нормально описаны преимущества REST? Желательно без пафоса, что SOAP отстой только потому, что он продвигается монстрами типа MS, а REST — это "тру", потому что его используют "тру гики".

... << RSDN@Home 1.2.0 alpha rev. 693>>

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Опять передержки. Я же писал сотню раз — EXE,JAR или не знаю что еще.
S>В это "не знаю что еще" входит джаваскрипт, выполняющийся в контексте веб-страницы? Или это непременно должно быть приложение с самостоятельным окном?

Уф! Ей-богу, надоело. Если интересует продолжение дискуссии — см. ветку с Геннадием Васильевым после выходных.

M>>Это вы не умеет его готовить

На тему статика vs. динамика тут уже столько копий сломано, уууу

Серьезным минусом JS являтся его слабая типизированность — это да

C>Есть ещё один недостаток — тормознутость. Где-то была демка на Silverlight 1.1 шахмат. Там можно было заставить играть JS движок против .NET движка. Скорость просчёта ходов отличалась на порядки. Хотя конечно для простых веб приложений скорость работы клиентского кода не очень важна.

Мы опять упираемся в вопрос о том, что считать веб приложением

Для сложной клиентской логики (включая навороченный UI) текущие реализации малопригодны. Но при этом наличие/отсутствие JS на клиенте никак не показывает сложность или простоту приложения

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>>>Это вы не умеет его готовить

На тему статика vs. динамика тут уже столько копий сломано, уууу

Серьезным минусом JS являтся его слабая типизированность — это да

C>>Есть ещё один недостаток — тормознутость. Где-то была демка на Silverlight 1.1 шахмат. Там можно было заставить играть JS движок против .NET движка. Скорость просчёта ходов отличалась на порядки. Хотя конечно для простых веб приложений скорость работы клиентского кода не очень важна.

M>Мы опять упираемся в вопрос о том, что считать веб приложением

Я конкретно про JS говорил, а так и XBAP можно веб-приложением считать, хотя оно отличается от standalone WPF приложения только рамочкой браузера и меньшими по умолчанию правами.

... << RSDN@Home 1.2.0 alpha rev. 693>>

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

dmz>Ну вероятно, надо сделать какие-то оговорки относительно характера приложений;

Причем очень существенные оговорки.

dmz> те приложения которые плохо вмещаются в возможности HTML/JS — это проблемы.

А rsdn.ru к таким приложениям не относится, между прочим.

dmz>Но ведь думаю очевиден тот факт, что hosted веб-приложение должно работать только в одной среде — той, которую мы сами выбрали с самого начала;

Серверная часть. На на клиенте все пока намного веселее — в отличие от десктопа где поддержка разных ОС только по отдельному желанию заказчика, для веба вполне нормальное, фактически обязательное требование поддерживать как минимум IE и FF.

dmz> нам не надо заботиться о развертывании,

Надо. Потому что не всегда у нас одна инсталляция на весь мир, не всегда владелец сайта содержит в своем штате программистов или оплачивает в том числе и развертывание на своих машинах.

dmz> мы можем использовать языки сколько угодно высокого уровня и любые библиотеки и средства

На сервере.

dmz>, не заботясь о том, сколько место это все займет и отукда возьмется у пользователя. Есть еще много вещей, которым можно не придавать особенного значения при разработке web-приложений без существенного урона — версионность, например.

Зато есть масса вещей, которым можно не придавать значение на десктопе. Например потокобезопасности кода.

dmz>И т.п. согласитесь, тут есть существенные отличия от standalone приложений.

Отличия есть безусловно, но это не значит что веб-приложения в разработке проще.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1067 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Curufinwe, Вы писали:
C>Кто-то пытается читать WSDL кроме генератора проксей?

C>А человека обычно читает документацию. Строить взаимодействие с сервисом у которого нет документации, а только "самодокументирующиеся" примеры request/response — это экстрим какой-то.
Welcome to the real world, Neo.
Проблема в том, что даже если ты прочитаешь исчерпывающую доку по сервису, то нет никакой гарантии, что она содержит ссылку на доку по "соседнему" сервису.

C>P.S. может есть ссылка на статью (не книгу) где нормально описаны преимущества REST?
http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/
C>Желательно без пафоса, что SOAP отстой только потому, что он продвигается монстрами типа MS,
Идеологам REST совершенно наплевать, что и кем продвигается.
C> а REST — это "тру", потому что его используют "тру гики".

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Curufinwe, Вы писали:
C>Я конкретно про JS говорил, а так и XBAP можно веб-приложением считать, хотя оно отличается от standalone WPF приложения только рамочкой браузера и меньшими по умолчанию правами.
А также, вроде как, улучшенной интеграцией с навигационной моделью браузера.
Что, в целом, позволяет его считать веб-приложением.

... << RSDN@Home 1.2.0 alpha rev. 677>>

S>>При этом ты считаешь Java безусловно превосходящей технологией для клиента (забывая пояснить — почему)

PD>Опять передержки. Я же писал сотню раз — EXE,JAR или не знаю что еще. Надоело.

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

Например.

Для того, тобы показать человеку карту достопримечательностей Стамбула, мне всего-то и надо, чтобы дать ему ссылку: http://www.adriyatik.com/cms/index.php?id=822&no_cache=1

Для того, чтобы показать человеку фотографии достопримечательностей Стамбула, я могу отослать его на http://flickr.com/map/ , сопроводив его небольшой инструкцией

Для того, чтобы сделать то же самое с Google Earth, человеку придется его скачать, установить, скачать с сайта файл в формате KML, импортировать его в Google Earth, потом только найти то, что ему нужно. Причем функциональности, подобной Flickr Worldmap там нет и не предвидится.

При всем при этом Google Earth рвет обе ссылки, как тузик грелку, в случае, если мне просто хочется побродить по свету, посмотреть на 3-Д модели зданий и так далее.

В идеализированном варианте, когда в мире есть Одна Единственная Операционная Система (тм), а все приложения разворачиваются по технологии One-CLick, то только тогда, быть может, имеет смысл говорить об exe, jar и так далее

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

M>>Мы опять упираемся в вопрос о том, что считать веб приложением

C>Я конкретно про JS говорил, а так и XBAP можно веб-приложением считать, хотя оно отличается от standalone WPF приложения только рамочкой браузера и меньшими по умолчанию правами.

Веб-приложение — это веб-страница + сервер. Даже самый навороченый яваскрипт нельзя назвать веб-приложением, если он ничего не делает

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

S>Читать хотя бы http://www-db-out.research.bell-labs.com/cm/cs/who/dmr/chist.html до просветления. Там написано, какие именно конкурентные преимущества были у языка С, и которые обеспечили ему успех. Можешь, к примеру, поинтересоваться, как выглядели строковые константы в "безраздельно царствующем" на момент разработки C Фортране-66.

Господи, ты хоть кур-то не смеши. Я на этом Фортране 8 лет программировал, и уж поверь, про текстовую обработку в нем все знаю.

И читай внимательно

>Да и идеи тоже нет, честно если сказать, ничего нового вы не придумали, все уже было, в PL/1, Алгол-68, Паскале.

Царствует Фортран . Все идеи были не в нем, а в PL/1, Алгол-68, Паскале (и не только, конечно, но я не про ООП и не про Лисп сейчас говорю) , т.е. до С. Идей в Фортране не было, точнее , они были, но образца 1954 года. Но он царствует. А у конкурентов есть идеи. Но они не царствуют, провалились. А у С нет идей по сравнению с конкурентами, но он будет царствовать. Теперь понятно ?

S>Так что параллелей с твоим случаем я не вижу.

Я могу еще несколько таких же параллелей накидать. Но какой смысл — ты же и без того истину знаешь, это же примерно то же самое, что христианина убеждать , что Бога нет.

Так чтто спорить с тобой мне попросту неинтересно. Ну на что мне, скажи на милость, знание деталей сошествия святого духа на праведника в момент сотворением им молитвы о даровании хлеба насущного, если я не уверен в том, что бог есть и хочу найти альтернативу этой концепции ? А мне в ответ — а как же в ващей концепции с хлебом и духом дела обстоять будут ?

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

L>А раздражает — масштабность подхода.

А можно поинтересоваться, кому масштабность подхода разрешена, а кому нет ?

>Вместо того чтобы посмотреть по сторонам и увидеть что люди наработали в этом направлении за последний десяток лет

И кому разрешено посмотреть на то, что люди наработали, критическим взглядом ?

>так Коперника и Галлилея тоже гнобили".

Я далек от мысли сравнивать себя с Коперником, но ведь и ему можно было возразить — вы чего это на систему Птолемея набросились, она ведь работала 1500 лет, по ней вычисляли, и даже порой довольно успешно. Так что бросьте вы это дело, уважаемый Коперник, и лучше "посмотрите по сторонам и увидете, что люди наработали в этом направлении за последние полтора тысячелетия".

Так что спасибо за пример

Кстати, Коперника лично никто не гнобил. Не успели. Потом сообразили.

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

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

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

Попробуйте следовать до конца своему принципу и подвергать сомнению не только мнения других людей но и своё собственное.

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

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

Пока мыши едят динозавров, не мог бы ты как член RSDN Team попросить кого-то из авторов этих мышей , чтобы при нажатии "Показать положение в теме" раскрывалось не все дерево топика, а только верхний его уровень для всех подветок, кроме ветки с этим сообщением. Как это, к примеру, regworks делает — только те ветви, что я хочу , и открыты, а не весь реестр. Он, конечно, всего лишь презренное десктопное приложение, но делает это без всяких проблем из справочника. Между прочим, дипломная работа нашего выпускника.

А то, извини, мне уже надоело смотреть на "Загрузка... Кликните для отмены".

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

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

>>Да и идеи тоже нет, честно если сказать, ничего нового вы не придумали, все уже было, в PL/1, Алгол-68, Паскале.
Угу. Ну тогда расскажи мне, что же привело к успеху С? Идей, значит, не было. Значит, были какие-то другие преимущества? В статье, между прочим, упомянуто, как опыт разработки мультикса на PL/1 потребовал языка с другими идеями.

PD>Царствует Фортран . Все идеи были не в нем, а в PL/1, Алгол-68, Паскале (и не только, конечно, но я не про ООП и не про Лисп сейчас говорю) , т.е. до С. Идей в Фортране не было, точнее , они были, но образца 1954 года. Но он царствует.
М-м. Напомни мне, пожалуйста, какая ОС была написана на Фортране?

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

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

PD>Ну на что мне, скажи на милость, знание деталей сошествия святого духа на праведника в момент сотворением им молитвы о даровании хлеба насущного, если я не уверен в том, что бог есть и хочу найти альтернативу этой концепции ? А мне в ответ — а как же в ващей концепции с хлебом и духом дела обстоять будут ?
Удачи. Найдешь альтернативу — напиши.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>Про мобильные приложения можно умолчать — полностью переносимых не так много, как хотелось бы

Слишком рано. Области совсем немного лет. Ситуация примерно та же, как с вопросом о переносимости программ для OS/360-370 — RSX-11 / UNIX — MS-DOS. Тогда даже программы в исходных кодах не очень легко переносились. Помню книгу "Мобильность программ на Фортране, начало или 80-х"

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

S>>>При этом ты считаешь Java безусловно превосходящей технологией для клиента (забывая пояснить — почему)

PD>>Опять передержки. Я же писал сотню раз — EXE,JAR или не знаю что еще. Надоело.

M>Для того, чтобы убедить пользователя скачать и установить что-либо, это что-либо должно обладать явными преимуществами по сравнению с вебом.

Вообще говоря, я уже достаточно в мыслях далек от этой ветки дискуссии. Увы, но единственно, кто понял, что я хотел сказать, это Геннадий Васильев, и я с ним на той неделе продолжу, но, похоже, несколько в ином направлении. Два дня есть на обдумывание ответа ему. Извини, но я физически не в состоянии отвечать всем.

Что же касается "убедить пользователя скачать и установить что-либо" — а не кажется ли тебе, что вопросы, обсуждаемые в русле философии программирования (точнее, базовых принципов ИТ — какие мы тут к богу философы!) должны определяться не только тем, удастся ли убедить пользователя, что стоит потратить еще один клик, даже если это ему и непонятно зачем. А то ведь если по этому пути пойти, то может оказаться, что развитие технологии и вектор этого развития определяется числом кликов пользователя.
А это не постройка собачьих будок, эта технология оказывает решающее влияние на развитие общества...

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

Совести не хватает — народ в тиме занят не меньше чем я, поэтому "пользоваться положением" мне неудобно.

PD>А то, извини, мне уже надоело смотреть на "Загрузка... Кликните для отмены".
Угу, понимаю.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>М-м. Напомни мне, пожалуйста, какая ОС была написана на Фортране?

PRIMUS тебе известен ? Это не ОС, правда, это только подсистема многопользовательского терминального доступа под управлением OS/360.
В общем, нечто, напоминающее Terminal Server + Remote Desktop.

Ждем реализации Terminal Server на JavaScript

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

F>Попробуйте следовать до конца своему принципу и подвергать сомнению не только мнения других людей но и своё собственное.

Именно этим я сейчас и занимаюсь.

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

PD>Что же касается "убедить пользователя скачать и установить что-либо" — а не кажется ли тебе, что вопросы, обсуждаемые в русле философии программирования (точнее, базовых принципов ИТ — какие мы тут к богу философы!) должны определяться не только тем, удастся ли убедить пользователя, что стоит потратить еще один клик, даже если это ему и непонятно зачем. А то ведь если по этому пути пойти, то может оказаться, что развитие технологии и вектор этого развития определяется числом кликов пользователя.
PD>А это не постройка собачьих будок, эта технология оказывает решающее влияние на развитие общества...

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

Эххх... Придется ждать понедельника

Приятных выходных!

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что же касается "убедить пользователя скачать и установить что-либо" — а не кажется ли тебе, что вопросы, обсуждаемые в русле философии программирования (точнее, базовых принципов ИТ — какие мы тут к богу философы!) должны определяться не только тем, удастся ли убедить пользователя, что стоит потратить еще один клик, даже если это ему и непонятно зачем. А то ведь если по этому пути пойти, то может оказаться, что развитие технологии и вектор этого развития определяется числом кликов пользователя.
О! Здравая мысль!
Совершенно верно — развитие технологии и вектор этого развития определяется числом кликов пользователя. Осталось убедить тебя прочесть хоть что-то базовое по usability, и можно поручить спроектировать несложное приложение

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>Ну, в целом развитие IT этим, в конченом итоге, и определяется — количеством кликов, которые необходимо сдлеать пользователю

Ты уверен, что пользователю надо кликать на

http://www.rsdn.ru/Users/1.aspx

и количеством этих кликов определится его развитие ?

M>Приятных выходных!

Спасибо.

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

S>О! Здравая мысль!
S>Совершенно верно — развитие технологии и вектор этого развития определяется числом кликов пользователя.

Чудная вообще-то мысль. Надо будет на выходных ее продумать. Интересные аналогии можно сделать. Ну, к примеру, развитие самолетостроения определяется числом датчиков в кабине пилота.

А пока что мне вспомнилось только одно — сделайте программу, которой сможет пользоваться и дурак, и только дурак захочет ею пользоваться.

>Осталось убедить тебя прочесть хоть что-то базовое по usability, и можно поручить спроектировать несложное приложение

Тебе все время очень хочется меня обидеть. Напрасно. У меня огромный запас терпения. Я же преподаватель, и должен его иметь для нерадивых студентов

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

M>>Ну, в целом развитие IT этим, в конченом итоге, и определяется — количеством кликов, которые необходимо сдлеать пользователю

PD>Ты уверен, что пользователю надо кликать на

PD>http://www.rsdn.ru/Users/1.aspx

PD>и количеством этих кликов определится его развитие ?

Уверен

Например, никто из участников этого форума не сможет открыть эт ссылку в Янусе, если ее пришлют по аське. А ъотелось бы

А IT к тому и идет — чтобы упростить раоту со сложными вещами

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

Мне немного странно что я рассказываю такие вещи научному сотруднику, но я всё же попробую.

Так вот — в научном мире все открытия так или иначе опирались на уже существующие знания. Перед тем как учёный высказывал какие-то идеи он для начала завоёвывал право называться учёным — долго и упорно учился. Лобачевский создал свою геометрию вовсе не потому что он плохо знал Евклидову геометрию. Упомянутый Коперник очень даже неплохо разбирался как работает система Птолмея. И прочая, прочая, прочая. Ты же демонстрируя безграмотность в вопросе выдаёшь её за светлый полёт мысли, прикрываясь именами людей которые тут вообще ни сном ни духом, рассказываешь байки о пользе прогресса и прочая и прочая.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

L>Так вот — в научном мире все открытия так или иначе опирались на уже существующие знания.

Дано три слова: "HTTP", "IP", "предшествует". Задача: составить исторически корректное высказывание из этих трёх слов.

L>>Так вот — в научном мире все открытия так или иначе опирались на уже существующие знания.
ГВ>Дано три слова: "HTTP", "IP", "предшествует". Задача: составить исторически корректное высказывание из этих трёх слов.

Нет. Дано ещё одно слово — "PDAP" (сокращение от Pavel Dvorkin Application Protocol). Нетрудно догадаться, что даже если он будет заимплеменчен на следующей неделе, то всё равно и IP, и HTTP ему предшествуют.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

M>>>Ээээ... Не понял. GMail доступен через веб-интерфейс и на тех же телефонах, например

S>>верно, доступен....инстоляхи с win 98 тоже доступны — однако ставят winXP. странно да?

M>Не поял, причем тут это

поясняю...эволюция использования gmail на WM выглядит примерно так

1) веб интерфейс ....тормозилово
2) закачка JAVA апплета доступа к gmail ...после чего возвращение назад к веб реализации — издевательство почище перехода с XP на win98

M>>>>Ээээ... Не понял. GMail доступен через веб-интерфейс и на тех же телефонах, например

S>>>верно, доступен....инстоляхи с win 98 тоже доступны — однако ставят winXP. странно да?

M>>Не поял, причем тут это

S>поясняю...эволюция использования gmail на WM выглядит примерно так

S>1) веб интерфейс ....тормозилово
S>2) закачка JAVA апплета доступа к gmail ...после чего возвращение назад к веб реализации — издевательство почище перехода с XP на win98

Хех

Надо оперой пользоваться

Но как я уже говорил:

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

S>>Совершенно верно — развитие технологии и вектор этого развития определяется числом кликов пользователя.
PD>Чудная вообще-то мысль. Надо будет на выходных ее продумать. Интересные аналогии можно сделать. Ну, к примеру, развитие самолетостроения определяется числом датчиков в кабине пилота.

Абсолютно верно! Чем меньше датчиков и элементов управления при одинаковом уровне функциональности и управляемости самолета — тем он лучше. Потому что управлять им проще, вероятности ошибиться меньше и значит самолет:
1. надежнее и безопаснее
2. дешевле в плане подготовке пилотов на него.

И конструкторы всегда стараются сделать управление самолетом максимально возможно простым (естественно, не в ущерб функциональности).

И вообще развитие всей техники идет так чтобы:
1. повысить эффективность (мощность, возможности и т.д.)
2. сделать использование максимально простым при той же общей функциональности.

И в ИТ в точности так же.

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

L>>>Так вот — в научном мире все открытия так или иначе опирались на уже существующие знания.
ГВ>>Дано три слова: "HTTP", "IP", "предшествует". Задача: составить исторически корректное высказывание из этих трёх слов.

L>Нет. Дано ещё одно слово — "PDAP" (сокращение от Pavel Dvorkin Application Protocol). Нетрудно догадаться, что даже если он будет заимплеменчен на следующей неделе, то всё равно и IP, и HTTP ему предшествуют.

Предшествуют, предшествуют. С той лишь разницей, что из них один является транспортным, а второй — прикладным (хотя его и используют в качестве транспортного). А протокол прикладного уровня, вообще говоря, всегда разрабатывается под текущую задачу и всегда его проектирование сталкивается с необходимостью учесть ненадёжность среды передачи данных. Даже если формировать http-запросы, всё равно прикладная программа должна предусматривать возможность того, что запрос не дойдёт, или ответ не дойдёт, или ответ придёт по истечении таймаута и т.д., и т.п. И по-любому будут и требования к последовательности сообщений, и требования к их содержанию, и ещё раз — т.д. и т.п. Общая проблематика известна любому, кто хоть раз писал распределённые приложения.

И если ставить исходную задачу именно так: "связать компоненты приложения", то выбор подложки под это самое связывание — вопрос далеко не первостепенный. В конечном итоге на его месте может оказаться RMI, XML/RPC, HTTP(S), "чистый" TCP/IP и т.п. Главное — удовлетворить тем требованиям, которые предъявляются к связи в контексте приложения. Насколько я понял, у Павла нет задачи любой ценой использовать протоколы, широко распространённые в web, основная проблема совсем в другом.

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

M>Хех

Надо оперой пользоваться

M>Но как я уже говорил:
M>

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

Рассуждение совершенно "в сторону", но тем не менее.

Электронная почта (если иметь в виду почтовые программы для человека) — это настолько простенькая задача сама по себе, что её можно "положить" на всё, что душе угодно. Функционалу-то, раз-два и обчёлся.

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

AVK>Серверная часть. На на клиенте все пока намного веселее — в отличие от десктопа где поддержка разных ОС только по отдельному желанию заказчика, для веба вполне нормальное, фактически обязательное требование поддерживать как минимум IE и FF.

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

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

F>Еще есть подтип "веб" приложений, которые на самом деле являются интранет приложениями, работающими только в корпоративной сети заказчика (данная подветка растет из моей истории о таких приложениях).
F>Для них вполне нормальным является требование качественно поддерживать только один браузер (обычно ИЕ), закрепленный корпоративным стандартом. Поддержка остальных — только как бонус.

На это у меня тоже есть пример. Новая платформа Паруса будет с несколькими клиентами, причем, скорее всего, среди них будет и веб-клиент. Прототип онного имеется в продакшене как раз таки с поддержкой IE-only (под названием веб-интерфейс к КОР, если интересно). Так вот, разработка веб-клиента значительно сложнее смарт-клиента, при том что функционал его меньше.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1067 on Windows Vista 6.0.6001.65536>>

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

S>Совершенно верно — развитие технологии и вектор этого развития определяется числом кликов пользователя.

Скорее наоборот: развитость технологий оказывает решающее влияние на количество кликов пользователя. Не было бы графического интерфейса — нечем было бы и кликать.

S>Осталось убедить тебя прочесть хоть что-то базовое по usability, и можно поручить спроектировать несложное приложение

Эт точно. После чтения книг по usability только простые приложения и можно писать.

Кстати, самый удобный и эргономичный интерфейс пользователя, который я видел — это были терминалы Wyse с плоским экраном и янтарным свечением. Режим — 25x80. Глаза не устают совершенно. Для большинства "деловых приложений" (информационных систем с полным отсутствием требований к реальному времени) этого добра хватает с головой, ушами и пятками. Ещё принтер — и полное счастье.

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

F>Абсолютно верно! Чем меньше датчиков и элементов управления при одинаковом уровне функциональности и управляемости самолета — тем он лучше.

[...]

F>И в ИТ в точности так же.

Суждение в целом верное, но будучи размещённым в цепочке доказательств ошибочного тезиса приводит к абсурду: требованию опровергнуть корректное высказывание.

Мораль: не всегда высказывание правильных мыслей оказывается к месту.

Здравствуйте, AndrewVK, Вы писали:
AVK>На это у меня тоже есть пример. Новая платформа Паруса будет с несколькими клиентами, причем, скорее всего, среди них будет и веб-клиент. Прототип онного имеется в продакшене как раз таки с поддержкой IE-only (под названием веб-интерфейс к КОР, если интересно). Так вот, разработка веб-клиента значительно сложнее смарт-клиента, при том что функционал его меньше.

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

С другой стороны, сама природа целевой платформы (если про нее знать) оказывает сильное влияние на внешнюю структуру приложения.
К примеру, если бы Google Search писался как win32 клиент, его UI 100% был бы совсем другим. А парни, которые бы портировали его в веб, матерились бы со страшной силой.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Рассуждение совершенно "в сторону", но тем не менее.
ГВ>Электронная почта (если иметь в виду почтовые программы для человека) — это настолько простенькая задача сама по себе, что её можно "положить" на всё, что душе угодно. Функционалу-то, раз-два и обчёлся.
Ага. Поэтому меня неизменно удивляет тот факт, что уже двадцать с лишним лет прогрессивное человечество не может сделать приличного почтового клиента.
Ни один из существующих клиентов не позволяет эффективно работать с бизнес-почтой. Вот у меня только в inbox лежит 1200 писем — это те, что я не сумел разложить по более чем 100 папок. На разгребание входящей почты уходит чертова уйма времени. Элементарное управление подписями к письмам сделано в Outlook 2007 на весьма примитивном уровне — меня парит каждый раз руками заменять сигнатуру на нужную. У меня еще куча претензий. Gmail революционизировал навигацию по почте; их поиск выглядит достаточно убедительно (хотя я не пробовал работать с ним по базе в ~4GB писем, большая часть из которых — мелкие).

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Left2,

Если уж продолжать аналогию с учёными, то им нужно знать то, что относится к исследованиям, касающимся, скажем так, мироздания и мироустройства. То есть нечто такое, что не только устаканивается раз и навсегда (во всяком случае — надолго), но ещё и многократно верифицируется на предмет совпадения с реальным миром. Но это вовсе не означает, что нужно изучать до посинения все диссертации всех предыдущих поколений.

А у нас в ИТ это именно так — всегда велик риск нарваться на обвинения в невежестве, если ты не изучил очередное завихрение мысли очередного комитета — что и как они назвали, и куда приткнули. Не находишь, что такая ситуация гораздо ближе к мракобесию, чем к науке?

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

S>Я начинаю приходить к выводу, что "простенькие" задачи как раз самые тяжелые.

ИМХО, всё проще — они скучные.

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

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

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

S>С другой стороны, сама природа целевой платформы (если про нее знать) оказывает сильное влияние на внешнюю структуру приложения.
S>К примеру, если бы Google Search писался как win32 клиент, его UI 100% был бы совсем другим. А парни, которые бы портировали его в веб, матерились бы со страшной силой.

А мы ничего не портировали. Хуже того, веб-клент как раз был первым.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>

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

M>Причем функциональности, подобной Flickr Worldmap там нет и не предвидится.

Я что то проглядел может, но geotagged картинки с Panoramino в гуглоземе есть уже больше года, причем покрытие фотками поплотнее будет.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>

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

S>Так что параллелей с твоим случаем я не вижу.

А я вижу:
1985й год. Молодой Павел Дворкин узнает о новом языке "С". (заметим, что изобретен он уже 15 лет как и достаточно прилично распространен в мире уже 10 лет и уже 5 лет как появился созданный на его основе конкурент С++). Тем не менее Павел, прочитав книжку, сразу же выдает вердикт, что язык никуда не годен, то, что он предлагает легко сделть и по старинке на Фортране. И, главное, нет никакой глобальной и революционной идеи. Фигня, в общем. Однако, через 3 года, он достает эту же книгу и осознает, что язык-то действительно полезен и очень практичен и вообще рулез.

2008й год. Уже не такой молодой Павел Дворкин поднимает тему о веб-приложениях, которые он немного поизучал (и даже поразрабатывал) и пришел к выводу, что какие-то они не очень и протоколы там какие-то так себе. (заметим, что HTTP существует уже лет 15, и сами веб-приложения уже сильно распространены лет 7). И выдает вердикт, что это дело никуда не годится, а в все то же самое легко разработать и по старинке, на десктопе на С. Вот если бы была какая-то действительно серьезная революционная идея... А так — фигня в общем.

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

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

Кажется, я наконец-то сам понял, чего я добиваюсь

Дело не в HTTP и не в XML. Дело в характере запроса и ответа.

Вот смотри

http://a.com/product.html?type=elephant&color=rose

Это фактически

com.a.html.product(type=elephant,color=rose)

То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры. Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.

Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели. Меня интересует в первую очередь слон, а уж потом розовый. Если розового слона не будет, я готов и другим (может быть) удовлетвориться, но стихи о розовом небе мне не нужны. Здесь не AND и не OR, здесь иерархия. Это же касается поиска.

Результат этого вызова отсылается в броузер. По существу этот результат есть смесь того, что может анализироваться только с помощью естественного интеллекта (или пишите анализатор текста на естественном языке) и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером). Ввиду отсутствия четких правил и наличия различных клиентов под разными ОС этот код неизбежно вынужден ограничиться неким минимумом возможностей, которые можно использовать на клиенте. Тем не менее удается написать такой код, который в состоянии нарушить корректную работу клиента, поэтому клиент вынужден принимать меры по блокировке части этого кода, что, впрочем, плохо удается, так что в итоге ОС вынуждена принимать меры по защите от самого клиента (Vista, выполнение IE под юзеровской УЗ).

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

А теперь рассмотрим SQL-сервер. Это тоже сервер

, но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов

А мог бы ? Мог. Вот представь себе

[SQLMethod] //

string[] GetColumnStrings(string database, string table, string column); // SELECT COLUMN
string[][] GetColumnsStrings(string database, string table, param string[] column) // SELECT COLUMN1, COLUMN2...

string[] GetColumnStringsByCondition( string database, string table, string column, cond condition, string value); // SELECT COLUMN... WHERE

и т.д.

Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.

А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных. Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.

А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов. При этом сайт а)полностью скрывает от внешнего мира свою структуру, б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.

Так что вызов сайта в этой модели выглядит так

com.a(XML request)

для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно. 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.

Вот, собственно, зачем мне тут понадобился XML. Собственно, мне не XML нужен, мне язык иерархических запросов нужен, и мне показалось, что XML для этого подходит. Я за XML стоять горой не буду, мне, в общем, все равно, лишь бы можно было запрос сформировать.

О протоколе. Это действительно маловажно. Если оставаться в рамках XML, то можно прекрасно обойтись без HTTP, Заменив его на XMLTP

. Если же считать HTTP частью транспорта, то можно и с ним. Иными словами, вполне приемлема схема с протоколом прикладного уровня XML, работающим поверх транспортного протокола HTTP/TCP/IP.

О семантике. Она, как всегда, за сценой и плохо формализуема. Ты писал

>что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.

Да, конечно, без согласования толку не будет, но в этом согласовании могут участвовать клиент и сервер. Возьмем опять SQL сервер. Если мы ничего не знаем о БД, то мы даже SELECT * FROM сделать не можем, поскольку не знаем FROM что. Но SQL сервер готов нам помочь, вернув свою схему, для этого надо только знать, где он находится, больше ничего. Схема определяет предметную область (об этом ниже) и структуру базы (сервера), и ее анализ, вообще говоря, позволить делать вполне осмысленные запросы. Тут есть и роль сервера, и роль клиента. Сервер вполне может представить эту схему не в виде DDL, а в чем-то более интеллектуальном, вроде объектного графа. Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.

За сценой пока что остался смысл всего этого. Тут я возвращаюсь к твоему примеру с tiff

ГВ>1. Что в природе вообще существует некий эдакий штук под названием .tiff-формат, котрый обрабатывается вон той подпрограммой.
ГВ>2. Что вроде бы, он должен быть картинкой.
ГВ>3. Что если он встретит узел с названием <picture> (условно), у которого есть атрибут с названием "url", то этот самый "url" является не чем-нибудь, а именно URL в соответсвии с подобающими спецификациями (иначе это будет ошибка)
ГВ>4. Что вычисленный шагом ранее URL содержит некоторый такой известный браузеру штукЪ под названием "расширение файла",
ГВ>5. ...или, что в том же узле picture посредством другого атрибута указан "content/type", сведения из которого отменяют полученные на ш. 4,
ГВ>6. Что загрузив некие невнятные данные с этого URL, опираясь на сведения о content/type можно эти данные затолкнуть вон той вот подпрограмме, которой нужно кроме того отдать всякие графические контексты и прочую требуху — нечто, наверное, нарисуется на экране пользователя.

Все так. Кстати, это же верно и для запросов. Ну подадим мы на запросе

type=elephant&color=rose.

Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.

Но в действительности все далеко не так плохо обстоит. Гарантии , конечно, нет, но, положа руку на сердце — тебе часто встречались .tiff файлы, содержащие не картинку ? Может, и встречались, но вряд ли часто. Идея расширений на удивление хорошо работает. Я сам брошу камень в того, кто предложит по расширениям однозначно судить о содержании файла, но ведь в 99.9% случаев это верно! По существу расширения — это некий лексикон, вошедший в большинство современных естественных языков (не всех, я совсем не уверен, к примеру, насчет LANGUAGE_MUMBO_JUMBO

. А и в пределах самого языка «слон» — это, как правило, все же животное известного вида с хоботом, а не что-то иное. Это не работает на 100%, несомненно, но, в общем, работает. А делая запрос к Гуглу, мы это как-то учитываем ? Точнее, Гугл как-то разбирается в том, что , найдя на странице розового слона, надо проанализировать текст и на основе этого анализа отнести страницу к тем, которые надо выдавать на запрос «вечеринка выпивка» ? Вряд ли

О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ? Ответ прост — если речь идет о вводе данных (стандартном действии), то для этого и надо использовать стандартный класс окон (диалоги), если же речь идет о действиях явно нестандартного вида, то надо создавать свое окно, тем более, что в диалоговых окнах некоторые возможности, легко и просто реализуемые в своих окнах, реализуются с трудом или вообще не реализуются (например, перехват сообщений в петле модального диалога реализуется только с вывертом, именуемым хуком, в то время как в своем окне он реализуется элементарно). То же и здесь. Если речь идет о вводе данных и отсылке их на сервер — незачем велосипед изобретать. Если же мы собираемся писать PhotoShop для сети

, то работать он будет на клиенте, а для связи с сервером использовать некую часть, реализуемую с помощью стандартных средств (окна типа диалога, будет это окно частью иного процесса или же просто окном диалоговых интернет-окон — это не самое важное, хотя я склоняюсь ко второму). Так что клиент должен заниматься своим делом, а сервер своим. А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.

И последнее. Сколько это будет стоить ? Сумасшедшие деньги. Без всякого сомнения. Будет ли это реализовано ? Не знаю. Знаю одно — нынешняя модель явным образом начинает переживать самое себя. Ее развитие, в силу заложенного в нее подхода, не соответсвующего объектной модели, ведет к тому, что в ней то и дело принимаются решения ad hoc, что приводит к появлению в ней заплат, а потом заплат на заплате. Раньше или позже сложность и внутренняя нелогичность этой модели превысит определенный порог, после чего появится некая белая мышь и погубит этих динозавров. Вполне возможно, что эта мышь будет совсем не похожа на то, что я описал.

В заключение один простой пример. В 1990 году появляется Windows 3.0, в 1995 — Windows 95. Обе приняты на ура. В обе MS вложила сумасшедшие деньги. А теперь представь себе, что в эйфории от успеха этих систем в MS приняли бы решение продолжать их развитие и нового не создавать. Это развитие, безусловно, было бы успешным (оно и было, кто назовет Windows 98 и ME провалом ?). В общем, примерно так до 2000 года все шло бы прекрасно, несмотря на то, что внутренняя структура Windows 9x чудовищна и представляет собой заплату на заплате. А вот после 2000 года (а может, 2005, а может, и 2010) все быстро пошло бы вниз. Потому что растет и развивается конкурент — Линукс. У него с этим самым usability проблемы на проблеме, но внутренняя его структура разумна и корректна. Так что не начни MS разработку линии NT (и кстати, пригласив для этого специалиста со стороны, видимо, опасаясь того, что свои специалисты могу Windows 9x Enhanced соорудить

) — я думаю, позиции линуксоидов были бы сейчас на порядок более обоснованными, чем мы имеем в действительности. Usability в Линуксе, если взяться как следует, привести в божеский вид можно. Из ядра Windows 9x сделать нормальное ядро современной ОС нельзя.

И уж совсем в заключение. Заменив вызов

com.a.html.product(type=elephant,color=rose)

на

com.a(XML request)

можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид

Internet(XML request)

а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.

Но я уже слышу топот копыт. Ко мне стремительно приближается сферический конь в вакууме и я начинаю ощущать вокруг себя ауру безвоздушного пространства. Так что развивать это направление не буду.

Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?

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

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

А в чём разница? Почему ты считаешь, что вместе с кодом 404 нельзя отправить нормальный ответ, возможно, с подсказками?

PD>Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.

Вот для этого и нужен content type.

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

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

S>>Так что параллелей с твоим случаем я не вижу.

F>А я вижу:
F>1985й год. Молодой Павел Дворкин узнает о новом языке "С". (заметим, что изобретен он уже 15 лет как и достаточно прилично распространен в мире уже 10 лет и уже 5 лет как появился созданный на его основе конкурент С++).

Жаль, нет движения во времени. Отправить бы тебя в 1980 , дать колоду перфокарт...

Здравствуйте, Pavel Dvorkin,

Отвечу где-то за полночь по твоему времени. Кратко, как понимаешь, тут не получается.

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

M>Уверен

И все же я думаю, что кликать на нем не стоит. Он может и обидеться

ГВ>>Рассуждение совершенно "в сторону", но тем не менее.
ГВ>>Электронная почта (если иметь в виду почтовые программы для человека) — это настолько простенькая задача сама по себе, что её можно "положить" на всё, что душе угодно. Функционалу-то, раз-два и обчёлся.
S>Ага. Поэтому меня неизменно удивляет тот факт, что уже двадцать с лишним лет прогрессивное человечество не может сделать приличного почтового клиента.

Оооо! Threading и Conversations!!!

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

M>>Причем функциональности, подобной Flickr Worldmap там нет и не предвидится.

AVK>Я что то проглядел может, но geotagged картинки с Panoramino в гуглоземе есть уже больше года, причем покрытие фотками поплотнее будет.

Не знал, побежал посыпать голову пеплом

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

PD>можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид

PD>Internet(XML request)

Кстати. Интернет в целом, конечно, никакое не дерево, но элементы "деревянной" структуры в нем есть. В терминах рассматриваемого подхода деятельность Google за последние годы в плане поиска представляет собой не что иное, как попытку создать в Интернете это дерево, утвердив себя в качестве его корня

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>http://a.com/product.html?type=elephant&color=rose
PD>Это фактически
PD>com.a.html.product(type=elephant,color=rose)
Совершенно верно.
PD>То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры.
У сайта нет классов и методов. У сайта есть ресурсы, внутренняя структура которых экспонируется через слабо определенный навигационный интерфейс.
Характерные примеры экспонирования внутренней структуры сайта:
1. Прямые ссылки (<link>, <a>), которые нативно поддерживаются в html/xhtml, а также являются типичными для XML-based форматов вроде ATOM или RSS. Принципиальная проблема — отсутствие возможности описать бесконечное пространство целевых адресов.
2. Ссылки на семейства URL. Например: формы в html/xhtml, URL Templates запланированные в XHTML 5.0 и встроенные в OpenSearch.

PD>Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.

PD>Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели. Меня интересует в первую очередь слон, а уж потом розовый. Если розового слона не будет, я готов и другим (может быть) удовлетвориться, но стихи о розовом небе мне не нужны. Здесь не AND и не OR, здесь иерархия.
Значит, автор сервиса неудачно выбрал структуру URL.
По традиции, иерархические параметры входят в Path:

http://a.com/products/elephant/rose.html

PD>Это же касается поиска.

PD>Результат этого вызова отсылается в броузер. По существу этот результат есть смесь того, что может анализироваться только с помощью естественного интеллекта (или пишите анализатор текста на естественном языке) и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером). Ввиду отсутствия четких правил и наличия различных клиентов под разными ОС этот код неизбежно вынужден ограничиться неким минимумом возможностей, которые можно использовать на клиенте. Тем не менее удается написать такой код, который в состоянии нарушить корректную работу клиента, поэтому клиент вынужден принимать меры по блокировке части этого кода, что, впрочем, плохо удается, так что в итоге ОС вынуждена принимать меры по защите от самого клиента (Vista, выполнение IE под юзеровской УЗ).
Ну, по какой-то причине браузер справляется с обработкой этого результата безо всякой помощи естественного интеллекта.

PD>Если рассмотреть web-сервисы, то тут картина уже несколько иная. Документированы списки методов и их параметры, документирован результат. Отсюда возможность вызывать эти web-сервисы не только из стандартного клиента (броузера), но и из произвольного для данной цели написанного клиента. Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет
Гарантий по сохранности интерфейса нет вообще нигде. Гарантии — не технический аспект, а административный. Точка.
Техническим аспектом может быть облегчение поддержки версионности интерфейсов.
В частности, поддержка discovery версий протоколов и negotiation по поводу версии.

PD>А теперь рассмотрим SQL-сервер. Это тоже сервер

, но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов
Это заблуждение. Современный SQL-cервер экспонирует свою внутреннюю структуру и список "методов" только в путь.
Опять же, SQL сервер нужно трактовать как некоторый набор ресурсов (записей), объединенных в таблицы и view. Набор "методов" жестко вшит в стандарт SQL: SELECT/INSERT/UPDATE/DELETE.
Как только ты узнал, что есть таблица с именем Orders и колонками ID, CustomerID, Amount, ты сразу можешь делать

select CustomerID, sum(Amount) as TotalAmount from Orders group by CustomerID order by 2 desc

PD>Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.
Так что API SQL-сервера — это набор таблиц, view, и хранимых процедур, которые он способен выполнять.

PD>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных. Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.

PD>А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов.
Совершенно верно. Так и делается; синтаксис XPath намеренно был сделан похожим на синтаксис URL.

PD>При этом сайт а)полностью скрывает от внешнего мира свою структуру,
Не очень понятно, что такое "своя структура". Есть две интерпретации понятия "структура сайта":
1. Направленный граф, который описывает страницы, входящие в сайт, и ссылки между ними. Так видят сайт поисковики.
2. Дерево, которое описывает взаимоотношения URL, независимо от фактических ссылок. Например, страница http://a.com/products/elephant/ будет считаться дочерней для http://a.com/products/, независимо от того, кто на кого ссылается. Так видит сайт человек, который пытается разобрать URL по частям.

Ни та, ни другая структура не имеют никакого отношения к тому, что творится "внутри" сервера.

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

There are three basic rules for URI design, born of collective experience:
1. Use path variables to encode hierarchy: /parent/child
2. Put punctuation characters in path variables to avoid implying hierarchy where
none exists: /parent/child1;child2
3. Use query variables to imply inputs into an algorithm, for
example: /search?q=jellyfish&start=20

PD>Так что вызов сайта в этой модели выглядит так
PD>com.a(XML request)
Что гораздо хуже, по очевидным причинам

PD>для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно.
Структура сайта — это то, по чему ты делаешь запрос. Если она изменилась, то твой XPath или что ты там придумал в качестве "некоторой иерархичной формы" ничего не найдет.

PD> 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
Вполне нормальный ответ — это 404. По стандарту, веб сервер должен дать в теле такого ответа те самые подсказки.
PD>Вот, собственно, зачем мне тут понадобился XML. Собственно, мне не XML нужен, мне язык иерархических запросов нужен, и мне показалось, что XML для этого подходит. Я за XML стоять горой не буду, мне, в общем, все равно, лишь бы можно было запрос сформировать.

PD>О протоколе. Это действительно маловажно. Если оставаться в рамках XML, то можно прекрасно обойтись без HTTP, Заменив его на XMLTP

.
Обойтись — можно; прекрасно — нет.
В отличие от самописанного протокола, HTTP поддерживает массу фич, даже если не рассматривать наличие готовых клиентов на всех платформах в качестве преимущества.
В частности, я в пятьсот седьмой раз напоминаю, что HTTP поддерживает кэширование и компрессию.

PD>Если же считать HTTP частью транспорта, то можно и с ним. Иными словами, вполне приемлема схема с протоколом прикладного уровня XML, работающим поверх транспортного протокола HTTP/TCP/IP.

PD>О семантике. Она, как всегда, за сценой и плохо формализуема. Ты писал

>>что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.

PD>Да, конечно, без согласования толку не будет, но в этом согласовании могут участвовать клиент и сервер. Возьмем опять SQL сервер. Если мы ничего не знаем о БД, то мы даже SELECT * FROM сделать не можем, поскольку не знаем FROM что. Но SQL сервер готов нам помочь, вернув свою схему, для этого надо только знать, где он находится, больше ничего. Схема определяет предметную область (об этом ниже) и структуру базы (сервера), и ее анализ, вообще говоря, позволить делать вполне осмысленные запросы. Тут есть и роль сервера, и роль клиента. Сервер вполне может представить эту схему не в виде DDL, а в чем-то более интеллектуальном, вроде объектного графа. Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.
Никаких проблем тут нет. WWW сервер уже представляет свою структуру, и есть несколько стандартов на эту тему.

PD>За сценой пока что остался смысл всего этого. Тут я возвращаюсь к твоему примеру с tiff

PD>type=elephant&color=rose.

PD>Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.
RTFM Content-Type.

PD>Но в действительности все далеко не так плохо обстоит. Гарантии , конечно, нет, но, положа руку на сердце — тебе часто встречались .tiff файлы, содержащие не картинку ?
Редко. Зато .php, возвращающие картинку — cплошь и рядом.
PD> Может, и встречались, но вряд ли часто. Идея расширений на удивление хорошо работает.
На удивление плохо она работает. Курить контент-тайп на предмет graceful degradation. Например, в сторону application/atom+xml, или хотя бы image/tiff. Какое расширение позволит клиенту сделать какие-либо выводы относительно содержимого, даже если само оно клиенту неизвестно?

PD>Я сам брошу камень в того, кто предложит по расширениям однозначно судить о содержании файла, но ведь в 99.9% случаев это верно!
Это заблуждение.
PD>По существу расширения — это некий лексикон, вошедший в большинство современных естественных языков (не всех, я совсем не уверен, к примеру, насчет LANGUAGE_MUMBO_JUMBO

Как раз гугл во всем очень хорошо разбирается в том, что он читает. К примеру, он умеет отличать plain text от html независимо от расширения.

PD>О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ? Ответ прост — если речь идет о вводе данных (стандартном действии), то для этого и надо использовать стандартный класс окон (диалоги)
Буэээ.
PD>, если же речь идет о действиях явно нестандартного вида, то надо создавать свое окно, тем более, что в диалоговых окнах некоторые возможности, легко и просто реализуемые в своих окнах, реализуются с трудом или вообще не реализуются (например, перехват сообщений в петле модального диалога реализуется только с вывертом, именуемым хуком, в то время как в своем окне он реализуется элементарно). То же и здесь. Если речь идет о вводе данных и отсылке их на сервер — незачем велосипед изобретать. Если же мы собираемся писать PhotoShop для сети

, то работать он будет на клиенте, а для связи с сервером использовать некую часть, реализуемую с помощью стандартных средств (окна типа диалога, будет это окно частью иного процесса или же просто окном диалоговых интернет-окон — это не самое важное, хотя я склоняюсь ко второму). Так что клиент должен заниматься своим делом, а сервер своим. А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.

PD>И последнее. Сколько это будет стоить ? Сумасшедшие деньги. Без всякого сомнения. Будет ли это реализовано ? Не знаю. Знаю одно — нынешняя модель явным образом начинает переживать самое себя. Ее развитие, в силу заложенного в нее подхода, не соответсвующего объектной модели, ведет к тому, что в ней то и дело принимаются решения ad hoc, что приводит к появлению в ней заплат, а потом заплат на заплате. Раньше или позже сложность и внутренняя нелогичность этой модели превысит определенный порог, после чего появится некая белая мышь и погубит этих динозавров. Вполне возможно, что эта мышь будет совсем не похожа на то, что я описал.

PD>И уж совсем в заключение. Заменив вызов

PD>com.a.html.product(type=elephant,color=rose)

PD>на

PD>com.a(XML request)

PD>можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид

PD>Internet(XML request)

PD>а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.
Угу. Я прямо-таки вижу как из интернета появляется Мистер Мускул и говорит "желаемое исполнено". Только вместо XML Request выступает WebRequest. Остальное — на 100% правда.

PD>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?

Надо полагать, речь идет о DNS.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

PD>>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?

S>Надо полагать, речь идет о DNS.

Вот здесь ты прав.

Все остальное ты так и не понял. Потому что ты просто не умеешь абстрагироваться от того, что ты знаешь.

S>У сайта нет классов и методов. У сайта есть ресурсы, внутренняя структура которых экспонируется через слабо определенный навигационный интерфейс

Будто я без тебя не понимаю, что есть у сайта или чего нет. Я о некоторой модели говорю (сайт с точки зрения ООП), а мне в ответ — да нет там класса, есть только ресурсы с навигацией... И как там кеширование будет ?

Продолжать дискуссию нет смысла.

PD>То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры. Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.

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

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

Почему и откуда это следует?

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

Что за тысячи ссылок?

А такой запрос не устроит: http://superstore/?item=elephant&preference=pink ? Какие преимущества гипотетического запроса?

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

http://php.net/some_func

404 с подсказками

PD>Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.

WSDL, например. Люьой вменяемый веб-сервис дает описание своего АПИ

> А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.

Не пойдет. Тогда нам нужно сначала поставить некую uber-ОС на все компьютеры

А что произойдет, если я пойду в интернет-кафе, в котором этой программы не установлено, а злой админ не позволяет ее ставить?

В этом плане гораздо блее интересен подход Эппл и ее приложениями для айфона в контексте Сафари. К сожалению, на данный момент будущего у такого мало из=за несовершенства браузеров в том числе.

Если приложение сможет запуститься само в контексте какой-нибудь песочницы (как сейчас — в браузере), то только тогда имеет смысл говорить о "просто приложениях", имхо

PD>И уж совсем в заключение. Заменив вызов

PD>com.a.html.product(type=elephant,color=rose)

PD>на

PD>com.a(XML request)

PD>можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид

PD>Internet(XML request)

PD>а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.

И какая разница? Мы все равно сообщаем, что мы хотим и от кого мы хотим. Только переносим это из строки запроса в передаваемые данные. Шило на мыло, в общем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

S>Ни один из существующих клиентов не позволяет эффективно работать с бизнес-почтой. Вот у меня только

Так по тебе Emacs GNUS плачет

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Надо полагать, речь идет о DNS.
PD>Вот здесь ты прав.

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

PD>Будто я без тебя не понимаю, что есть у сайта или чего нет. Я о некоторой модели говорю (сайт с точки зрения ООП), а мне в ответ — да нет там класса, есть только ресурсы с навигацией... И как там кеширование будет ?
Совершенно верно. Рассматривать интернет с точки зрения ООП не очень конструктивно. ООП вообще в распределенном мире работает очень плохо. Это медицинский факт.
Конструктивнее рассматривать интернет с точки зрения SQL, но тоже не очень хорошо — потому, что SQL подразумевает такие операции, выполнение которых в интернете заведомо приведет к чудовищным затратам вычислительных ресурсов.

Поэтому модель ресурсно-ориентированной сети в настоящее время немеряно рулит. Не потому, что она есмь единственное, что я могу воспринять своим убогим мозгом, а потому, что она хорошо соответствует техническим и психологическим реалиям.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>Как это изменится для десктоп приожения, которое с этими же сервисами будет работать?

Никак. Я это уже не обсуждаю.

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

M>Почему и откуда это следует?

Это моя точка зрения, которую я высказываю и обосновываю.

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

M>Что за тысячи ссылок?

Выдаваемых Гуглом, к примеру. Или поиском на этом же сайте

M>А такой запрос не устроит: http://superstore/?item=elephant&preference=pink ? Какие преимущества гипотетического запроса?

Ну я же объяснял, чем отличается иерархический запрос.

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

M>http://php.net/some_func

M>404 с подсказками

Да, конечно, но не в этом же дело.

PD>>Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.

M>WSDL, например. Люьой вменяемый веб-сервис дает описание своего АПИ

Дает.

>> А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.

M>Не пойдет. Тогда нам нужно сначала поставить некую uber-ОС на все компьютеры

Это сейчас за пределами обсуждения.

M>А что произойдет, если я пойду в интернет-кафе, в котором этой программы не установлено, а злой админ не позволяет ее ставить?

M>И какая разница? Мы все равно сообщаем, что мы хотим и от кого мы хотим.

В данном случае только "что" и не указываем "от кого". От Интернета в целом. Речь идет о DNS — запросе.

Не обижайся, но ты просто ИМХО не понял, о чем идет речь. Я уже не обсуждаю сейчас ни клиента, ни сервера, меня сейчас только запрос и ответ как таковой интересуют, точнее, форматы их и соответствие этих форматов объектной модели сайта и клиента, а также распределение функций между ними. Все остальное за пределами обсуждения.

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

M>>Что за тысячи ссылок?

PD>Выдаваемых Гуглом, к примеру. Или поиском на этом же сайте

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

Насколько я помню, тот же Гугл вполне способен выдавать результаты поиска (и не только) вполне себе в машиночитаемой форме (в их конкретном случае в XML)

M>>А такой запрос не устроит: http://superstore/?item=elephant&preference=pink ? Какие преимущества гипотетического запроса?

PD>Ну я же объяснял, чем отличается иерархический запрос.

Ну и в моем запросе я говорю: хочу слона (item=elephant), предпочтительно розового (preference=pink)

А чем отличается иерархический запрос, я, честно говоря, не понял

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

M>>http://php.net/some_func

M>>404 с подсказками

PD>Да, конечно, но не в этом же дело.

А в чем же?

M>>И какая разница? Мы все равно сообщаем, что мы хотим и от кого мы хотим.

PD>В данном случае только "что" и не указываем "от кого". От Интернета в целом. Речь идет о DNS — запросе.

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

Какой-то сферовакуумный конь получается

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>Ну и в моем запросе я говорю: хочу слона (item=elephant), предпочтительно розового (preference=pink)

M>А чем отличается иерархический запрос, я, честно говоря, не понял

Сформулируй (например, для Гугла) запрос вида

Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.
Павел, ты наверное как-то не так понял идею интернета.
В ней нет никаких языков запросов. Совсем. Когда я иду по адресу http://google.com?q=pink+elephant, я получаю доступ к уникальному ресурсу.
Благодаря тому, что реальная структура интернета от меня скрыта, гугл в ответ на это возвращает некоторый специальный ресурс.

А тепер, чтобы ты не обвинял меня в том, что всё время рассказываю только про то, что уже есть (хотя, имхо, перед тем, как изобретать свой порох, крайне полезно ознакомиться с существующими вариантами), поговорим об Универсальном Языке Запросов Выразительном Абсолютно (УЯЗВА).
Я правильно понимаю, что ты бы хотел чтобы такой язык существовал и поддерживался той альтернативой веб сервисам, которую ты пытаешься изобрести?

Тот запрос, который ты привел, сводится к предикатам первого порядка над объектами из некоторой примитивной модели.
Грубо говоря, это некоторое подмножество SQL. Осталось понять, насколько широк тот класс запросов, который ты собираешься потребовать от реализации.

Забегая вперед, поясню: REST подход к веб-сервисам состоит в отказе от попытки описать всё подряд некоторым языком запросов. Если тебе хочется получить свой язык запросов — пожалуйста, реализуй его поверх существуюшего протокола. Благодаря этому нет нужды расширять протокол для того, чтобы перейти от запросов "дай мне документы, содержащие слово Dvorkin", к запросам "дай мне заправки рядом с Красной Площадью". С точки зрения математики это два совершенно разных класса запросов, которые крайне тяжело реализовать в рамках одного языка. С точки зрения веба это всего лишь определенные ресурсы, URL к которым строится по определенным правилам. Причем правила не зашиты в протоколе, а передаются на машину пользователя в рамках "самозагружаемого" клиента.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

Ты бы еще мне объяснил сведение иерархии к реляционной модели.

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

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

M>>Ну и в моем запросе я говорю: хочу слона (item=elephant), предпочтительно розового (preference=pink)

M>>А чем отличается иерархический запрос, я, честно говоря, не понял

PD>Сформулируй (например, для Гугла) запрос вида

PD>Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.

Угу, а предлагаемый нами некий Универсальный Уравнитель это поможет нам сделать?
Такой запрос в общем случае нельзя составить. И никакой язык запросов нам в этом не поможет.

И HTTP здесь не причем. Потому что я могу составить параметры и отслать их POST'ом на мой сервер, пусть он корячится

А для гугла просто нет такого понятия, как приоритет. Но вот на hotels.de можно задавать запросы типа "Цюрих +/- 10 километров". Чем не ограничение?

Проблема далеко не в запросе, а в том, как этот запрос обрабатывать

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>Угу, а предлагаемый нами некий Универсальный Уравнитель это поможет нам сделать?
M>Такой запрос в общем случае нельзя составить. И никакой язык запросов нам в этом не поможет.

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

M>И HTTP здесь не причем. Потому что я могу составить параметры и отслать их POST'ом на мой сервер, пусть он корячится

Я же писал, что вопрос HTTP меня больше не волнует. Прочти внимательно.

M>А для гугла просто нет такого понятия, как приоритет.

Именно. Вот поэтому он сотни тысяч ответов даст, если туда сунуть слон розовый мамонт Сибирь самка... И даже Advanced Search не поможет.
>Но вот на hotels.de можно задавать запросы типа "Цюрих +/- 10 километров". Чем не ограничение?

Проблема далеко не в запросе, а в том, как этот запрос обрабатывать

Чтобы его обработать, надо найти подходящий язык. чтобы его сформулировать. Обычный поиск тут не работает

M>>Угу, а предлагаемый нами некий Универсальный Уравнитель это поможет нам сделать?
M>>Такой запрос в общем случае нельзя составить. И никакой язык запросов нам в этом не поможет.

PD>Почему нельзя ? Запрограммировать ты это бы смог — на С#, на Java, на чем хочешь. С таким же успехом можно это изложить средствами некоего иеррархического языка запросов

А причем тут запрос тогда?

К нам на сервер приходит запрос в каком-то виде, который мы понимаем. Мы его обрабатываем и возвращаем результат. Так ведь?

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

M>>И HTTP здесь не причем. Потому что я могу составить параметры и отслать их POST'ом на мой сервер, пусть он корячится

PD>Я же писал, что вопрос HTTP меня больше не волнует. Прочти внимательно.

M>>А для гугла просто нет такого понятия, как приоритет.

PD>Именно. Вот поэтому он сотни тысяч ответов даст, если туда сунуть слон розовый мамонт Сибирь самка... И даже Advanced Search не поможет.

Ну, если мы гвоорим о сферовакууме (а ведь мы уже не говорим ни про HTTP, ни про декстоп, а вообще непонятно о чем), то этот uberGoogle спокойно будет возвращать требуемые результаты в нужном формате.

То, что возвращает некий сервис полностью лежит на совести разработчика и никакой язык запросов тут не поможет.

>>Но вот на hotels.de можно задавать запросы типа "Цюрих +/- 10 километров". Чем не ограничение?

Проблема далеко не в запросе, а в том, как этот запрос обрабатывать

PD>Чтобы его обработать, надо найти подходящий язык. чтобы его сформулировать. Обычный поиск тут не работает

?

Я захожу на hotels.de, там есть один инпут: название_города и один селект: расстояние

При чем тут подходящий язык? На серверной стороне к нам придет два параметра: название_города и расстояние.

Вернемся к предлагаемой задаче:

Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.

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

А форматов этого запроса только для XML — десятки. И что?

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Почему нельзя ? Запрограммировать ты это бы смог — на С#, на Java, на чем хочешь. С таким же успехом можно это изложить средствами некоего иеррархического языка запросов
Непонятно, что такое "иерархический". Тот запрос, который ты попросил, в нем никакой иерархии нету.
Если ты считаешь дизъюнкции и конъюнкции предикатов иерархией — флаг в руки.

PD>Чтобы его обработать, надо найти подходящий язык. чтобы его сформулировать. Обычный поиск тут не работает
Таких языков есть. Я в свое время интересовался тем, какие вообще запросы люди делают.
В результате пришел к выводу, что универсальный язык если и можно построить, то выполнение запросов в нем за приемлемое время получить удастся уже вряд ли.
Удобнее под каждую задачу строить свой микро-язык.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Pavel Dvorkin,

Пришлось очень много думать и фильтровать. Скоро расшифрую, что за этим стоит (уж коль скоро обещался ответить чуть раньше). Пока в двух словах: в основном размышлять пришлось над вот этим:

PD>О семантике. Она, как всегда, за сценой и плохо формализуема.

На этом месте я выхлюпал 150 коньяку и продолжил думать. То есть это не нечто шокирующее, это оказалось много круче.

Здравствуйте, Pavel Dvorkin,

Твой постинг я разделил на три сильно неравных части: две из них состоят, преимущественно, из аналогий, и одна содержит ключевой, вопиющий, смысловой пропуск. С неё и начну.

PD>О семантике. Она, как всегда, за сценой и плохо формализуема. Ты писал

ГВ>>что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.

Павел, я это не случайно писал. Здесь как раз — главный момент.

PD>Да, конечно, без согласования толку не будет, но в этом согласовании могут участвовать клиент и сервер. Возьмем опять SQL сервер. Если мы ничего не знаем о БД, то мы даже SELECT * FROM сделать не можем, поскольку не знаем FROM что. Но SQL сервер готов нам помочь, вернув свою схему, для этого надо только знать, где он находится, больше ничего. Схема определяет предметную область (об этом ниже) и структуру базы (сервера), и ее анализ, вообще говоря, позволить делать вполне осмысленные запросы. Тут есть и роль сервера, и роль клиента. Сервер вполне может представить эту схему не в виде DDL, а в чем-то более интеллектуальном, вроде объектного графа. Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.

Для начала, попробуй сравнить два высказывания: "Схема [базы данных] определяет предметную область" и "Схема [базы данных] определяется предметной областью". Разницу понимаешь. Даже на таком простом уровне, как схема базы данных уже вовлекается масса предположений о действительной структуре (sic!) символического пространства предметной области. При этом схема базы данных неизбежно содержит какие-то допущения и аппроксимации.

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

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

Я вполне допускаю, что "розовый слон" может означать "никакой тяжёлой дури в радиусе 200 метров!" или ещё что-то в этом духе. Проблема в том, как передать это знание компьютеру. Компьютер "понимает" воплощённые символы и только их (в чём его преимущество перед людьми, если разобраться). Ответ здесь, в принципе, так же очевиден, как и сложен технически: нужно закодировать всё символическое пространство, которым оперирует конкретный пользователь, то есть перевести "абстрактные" символы в их специфическое воплощение и отсюда уже начать разворачивать сугубо технические вариации на тему клиент-сервер, HTTP-XML и иже прочая еси аки и наипаче.

PD>За сценой пока что остался смысл всего этого. Тут я возвращаюсь к твоему примеру с tiff

[overquotting died forever]

PD>Все так. Кстати, это же верно и для запросов. Ну подадим мы на запросе
PD>type=elephant&color=rose.

PD>Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.

Бу-га-га. Гугль, не к ночи будь помянут, ищет полнотекстовым поиском. AFAIK, такими фишками, как семантической интерпретацией они не заняты.

PD>Но в действительности все далеко не так плохо обстоит. Гарантии , конечно, нет, но, положа руку на сердце — тебе часто встречались .tiff файлы, содержащие не картинку ? Может, и встречались, но вряд ли часто. Идея расширений на удивление хорошо работает. Я сам брошу камень в того, кто предложит по расширениям однозначно судить о содержании файла, но ведь в 99.9% случаев это верно!

НО! Это плод того, что масса людей, формирующих файлы .tiff придерживаются этого соглашения. Это очень важно: наличие некоего документа (не обязательно в виде RFC), определяющего наполнение того или иного символа и соблюдение положений этого документа людьми. В рассматриваемом случае с браузером, если на месте .tiff окажется вот этот постинг, то браузер отбросит его как неправильный .tiff.

PD>По существу расширения — это некий лексикон, вошедший в большинство современных естественных языков (не всех, я совсем не уверен, к примеру, насчет LANGUAGE_MUMBO_JUMBO

Естественнно, google не разбирается в семантике. Я могу ошибаться, но, кажется, догадываюсь, в чём причина. Дело в том, что семантика тех или иных символов может в некоторой степени флуктуировать для тех или иных пользователей. Ну, например, я ищу розовых слонов, но не откажусь узнать, где устраивают вечеринки без тяжёлой дури. Кстати, здесь я цепляю очень сложную тему с "не откажусь". Я как бы не "за", но и не "против". Можно с лёгкостью перечислить, что именно нужно, но невероятно тяжело перечислить всё, от чего пользователь не отказалcя бы.

Предыдущее сообщение — это была часть 1.

Здравствуйте, Pavel Dvorkin,

Теперь много об аналогиях. Здесь я буду выступать в своеобычном апмлуа сетевого комментатора. Знаешь, вероятно, эдакий истерично-критиканский стиль.

PD>com.a.html.product(type=elephant,color=rose)

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

Болт! Сайт в данном случае ничего не экспонирует. Окромя допустимых аргуметов "type" и "color". Речи о ынутренней структуре тут и быть не может.

PD>Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.

Погоди. Не надо натягивать презерватив на покрышку. Это и не класс, и не методы. Это всего лишь поисковые запросы. Именно так к ним и следует подходить. Они по определению не претендуют на то, что их результат окажется стабильным в долговременном представлении.

PD>Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели.

Ха! Ну-ка, ну-ка, спецификацию модели в студию! Понимаешь, что имею в виду?

PD>Меня интересует в первую очередь слон, а уж потом розовый. Если розового слона не будет, я готов и другим (может быть) удовлетвориться, но стихи о розовом небе мне не нужны. Здесь не AND и не OR, здесь иерархия. Это же касается поиска.

О, как! Вот раз тебя интересует в первую очередь слон, как представитель млекопитающих-с-хоботом, то вот так об том и скажи. Компьютеры, они в Америке придуманы, а следовательно — ту-у-у-упы-ы-ые!

PD>Результат этого вызова отсылается в броузер. По существу этот результат есть смесь того, что может анализироваться только с помощью естественного интеллекта (или пишите анализатор текста на естественном языке)

В десятку! Да! И ещё не забудьте модель человека, как связной системы семантик, метасемантик, и мета-мета семантик.

PD> и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером).

Да какая разница — клиент это или сервер?

PD> Ввиду отсутствия четких правил и наличия различных клиентов под разными ОС этот код неизбежно вынужден ограничиться неким минимумом возможностей, которые можно использовать на клиенте. Тем не менее удается написать такой код, который в состоянии нарушить корректную работу клиента, поэтому клиент вынужден принимать меры по блокировке части этого кода, что, впрочем, плохо удается, так что в итоге ОС вынуждена принимать меры по защите от самого клиента (Vista, выполнение IE под юзеровской УЗ).

Повторюсь: пошёл он подальше, это самыый браузер. Без него управимся. Смартового напишем.

PD>Если рассмотреть web-сервисы, то тут картина уже несколько иная. Документированы списки методов и их параметры, документирован результат. Отсюда возможность вызывать эти web-сервисы не только из стандартного клиента (броузера), но и из произвольного для данной цели написанного клиента.

Э-э-э, батенька! Так "произвольного" или "для данной цели"? Эти явления нельзя смешивать. И с другой стороны, возьми, к примеру, WSDL с некоего сайта по имени www.rsdn.ru (вспомнилось вдруг, вообще — забыл даже, что там такое лежит), да попробуй расшифровать, что означают параметры методов и что с ними имеет смысл делать.

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

Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API. Ну, то есть, имеет, конечно, но весьма опосредованное. Во-вторых, тезис об экспонировании внутренней структуры имеет смысл только по отношению к некоторым объектам уровня интерпретации. Например, я понятия не имею (да и знать не хочу), что скрывается за дескриптором сокетов. Мне, как пользователю, важно, чтобы соглашения об использовании и допустимой последовательности вызовов соблюдались разработчиками sockets.

PD>А теперь рассмотрим SQL-сервер. Это тоже сервер

, но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов

PD>А мог бы ? Мог. Вот представь себе

PD>[SQLMethod] //

PD>string[] GetColumnStrings(string database, string table, string column); // SELECT COLUMN
PD>string[][] GetColumnsStrings(string database, string table, param string[] column) // SELECT COLUMN1, COLUMN2...

PD>string[] GetColumnStringsByCondition( string database, string table, string column, cond condition, string value); // SELECT COLUMN... WHERE

PD>и т.д.

Представил. Содрогнулся.

PD>Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.

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

PD>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных.

Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся!

PD>Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.

Стойка обретает суровую стабильность...

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

Ничего подобного. Здесь у тебя такой вагон допущений, что всё перечислять — времени жизни вселенной не хватит.

PD>Так что вызов сайта в этой модели выглядит так
PD>com.a(XML request)

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

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

Дык. Я вообще не могу представить для описания иерархических структур ничего лучше, чем S-expressions. XML — ну, я уже отписывался по этому поводу. Бастард и бастард, ничего более.

PD>О протоколе. Это действительно маловажно. Если оставаться в рамках XML, то можно прекрасно обойтись без HTTP, Заменив его на XMLTP

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

Твое сообщение

http://www.rsdn.ru/forum/message/2907037.1.aspx

про попытке вставить в Open Office Writer привело к безвременной смерти последнего. Эффект стабильный, пробовал 2 раза. Все же вставил и распечатал. Буду думать. Ответ не сегодня.

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

PD>Твое сообщение

PD>http://www.rsdn.ru/forum/message/2907037.1.aspx

PD>про попытке вставить в Open Office Writer привело к безвременной смерти последнего. Эффект стабильный, пробовал 2 раза. Все же вставил и распечатал. Буду думать. Ответ не сегодня.

Интересно. Я, конечно, недолюбливаю Open Source, но не до такой же степени.

У меня вставилось, версия 2.3.1.

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

По мелочам отвечу. С чем согласен — просто опустил.

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

ГВ>Болт! Сайт в данном случае ничего не экспонирует. Окромя допустимых аргуметов "type" и "color".

Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект. Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ? Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?

>Речи о ынутренней структуре тут и быть не может.

Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ? product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.

ГВ>Погоди. Не надо натягивать презерватив на покрышку. Это и не класс, и не методы. Это всего лишь поисковые запросы.

Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй.
Я думаю, ты понимаешь, что я не предлагаю садиться и эти классы писать. Это только модель для рассуждений. Но если она неверна — объясни, почему.

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

И что ? А для обычных, классических функций всегда гарантировано сохранение результата во времени ? Не говоря уж о рандомах, но возьми, к примеру, алгоритмы оптимизации. Изменили метод оптимизации — получили малость другой результат. Я уж не говорю, скажем, о функциях вывода на печать — тут очень многое может измениться.

PD>>Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели.

ГВ>Ха! Ну-ка, ну-ка, спецификацию модели в студию! Понимаешь, что имею в виду?

Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!

PD>> и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером).

ГВ>Да какая разница — клиент это или сервер?

Так я и говорю, что никакой. Разница та же — что и вызове callback в обычном приложении. Детали реализации.

PD>>Если рассмотреть web-сервисы, то тут картина уже несколько иная. Документированы списки методов и их параметры, документирован результат. Отсюда возможность вызывать эти web-сервисы не только из стандартного клиента (броузера), но и из произвольного для данной цели написанного клиента.

ГВ>Э-э-э, батенька! Так "произвольного" или "для данной цели"?

Не пойдет. Именно произвольного (т.е не обязательно броузера, а что захотим, то и напишем, и какими средствами захотим , такими и напишем, и будет он десктопным или нет — как захотим), но для данной цели. Если я писал в свое время такой клиент для задач оптимизации финансовых расчетов (реализуемых сервисом), то для задач предсказания погоды он не пойдет. Но мы этот клиент делали как десктопное приложение (для отладки), как код, вызываемый их Excel и т.д.
А вот если бы этот сервис вернул мне javascript, то пришлось бы либо исполнять это только из броузера, либо писать свой интерпретатор javascript и надеяться, что в ответе будет только часть, относящаяся к задаче, а не window.open(...), в противном случае придется свой броузер писать. Вот и все, что я хотел здесь сказать.

>Эти явления нельзя смешивать. И с другой стороны, возьми, к примеру, WSDL с некоего сайта по имени www.rsdn.ru (вспомнилось вдруг, вообще — забыл даже, что там такое лежит), да попробуй расшифровать, что означают параметры методов и что с ними имеет смысл делать.

Это к тому, что я распечатал и буду думать.

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

ГВ>Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API.

WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.

PD>>Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.

ГВ>Не совсем так. Ты постоянно, как я уже говорил, пытаешься натянуть презерватив на покрышкку, то есть расширить значение терминов до невероятных ширшот (или — широтей). Это неправильно. API — это интерфейс прикладных программ.

Можешь считать, что я расширяю это понятие до невероятных широт, если хочешь. То, что АПИ — интерефйс программ (и не обязательно прикладных) — это верно, но утверждать, что этот интерфейс должен состоять из описаний методов, типов и т.д — не согласен. Он может, вообще говоря, быть любым.

PD>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных.

ГВ>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся!

Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ?

PD>>Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.

ГВ>Стойка обретает суровую стабильность...

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

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

ГВ>Дык. Я вообще не могу представить для описания иерархических структур ничего лучше, чем S-expressions. XML — ну, я уже отписывался по этому поводу. Бастард и бастард, ничего более.

Черт с ним.

PD>>про попытке вставить в Open Office Writer привело к безвременной смерти последнего. Эффект стабильный, пробовал 2 раза. Все же вставил и распечатал. Буду думать. Ответ не сегодня.

ГВ>Интересно. Я, конечно, недолюбливаю Open Source, но не до такой же степени.

У меня вставилось, версия 2.3.1.

Если вставлять из ФФ, то такой эффект довольно часто проявляется. Лучше вставлять через insert special -> unformatted text

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

Здравствуйте, Pavel Dvorkin,

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

PD>О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ?

Боже мой! На этот вопрос давать "общий" ответ нельзя по определению. Всё решается на месте.

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

, то работать он будет на клиенте, а для связи с сервером использовать некую часть, реализуемую с помощью стандартных средств (окна типа диалога, будет это окно частью иного процесса или же просто окном диалоговых интернет-окон — это не самое важное, хотя я склоняюсь ко второму). Так что клиент должен заниматься своим делом, а сервер своим. А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.

Павел, не ведись ты на общую вакханалию. Приложения всегда были и будут именно "просто" приложениями.

PD>И последнее. Сколько это будет стоить ? Сумасшедшие деньги. Без всякого сомнения. Будет ли это реализовано ? Не знаю. Знаю одно — нынешняя модель явным образом начинает переживать самое себя. Ее развитие, в силу заложенного в нее подхода, не соответсвующего объектной модели, ведет к тому, что в ней то и дело принимаются решения ad hoc, что приводит к появлению в ней заплат, а потом заплат на заплате. Раньше или позже сложность и внутренняя нелогичность этой модели превысит определенный порог, после чего появится некая белая мышь и погубит этих динозавров. Вполне возможно, что эта мышь будет совсем не похожа на то, что я описал.

Здесь нужно вернуться к части первой моих ответов. Есть очень глубокий и хитрый фокус, котрый подкинул Керниган сотоварищи всей програмистской братии — C ("Си") распространился практически сам по себе, вместе с Unix-ом (в отечественной интерпретации — МОС, если не ошибаюсь). Фокус состоит в том, что C существенно проще, чем, скажем PL/1, но тем не менее, обеспечивает всё то же самое, что позволял PL, плюс ещё... Блин, вспомнить бы PL из институтского курса. Не, не буду.

PD>В заключение один простой пример. [skip, 9x, NT, etc.]

Значится так... Linux народился на свет в 1991. Windows NT обрела папочку в 1988:

Meanwhile Microsoft continued to develop Windows NT. The main architect of the system was Dave Cutler, one of the chief architects of VMS at Digital Equipment Corporation (later purchased by Compaq, now part of Hewlett-Packard). Microsoft hired him in 1988 to create a portable version of OS/2, but Cutler created a completely new system instead. (Наш человек! — Г.В.) Cutler had been developing a follow-on to VMS at DEC called Mica, and when DEC dropped the project he brought the expertise and some engineers with him to Microsoft. DEC also believed he brought Mica's code to Microsoft and sued. Microsoft eventually paid $150 million U.S. and agreed to support DEC's Alpha CPU chip in NT.

Я понимаю, что это автонезачёт, но взято отсюда.

Иными словами, аргументы из серии "Linux логичнее, чем Windows и Windows его боится и боялся отродясь" отправляются в лес жарить шашлык. Более чем уверен, что на момент выпуска NT (см. также материалы по теме OS/2) её разработчики про Linux, может, и знали чего, но так... Мало ли курьёзов в IT? Студенты, они такие — всё время вселенную потрясти пытаются, ну и пущай себе пытаются.

С другой стороны, DOS, в принципе, это не более, чем монитор прерываний, а не операционная система. Отсюда мораль: она не могла стать ни современной операционной системой, ни какой бы то ни было существенной ОС вообще. Вся причина её успеха в том, что MS вовремя подсуетилась с заказом от IBM. Более того, согласись, забавно, что "современная ОС" по каким-то мистическим причинам недалеко ушла от ОС 70-х. Я имею в виду Unix. Тогда как куда как более моладая DOS уже предана повсеместному порицанию.

Так что, не надо тасовать интерпретации фактов в угоду теории, это вредит и теории, и тасователю.

PD>И уж совсем в заключение. Заменив вызов
PD>com.a.html.product(type=elephant,color=rose)
PD>на
PD>com.a(XML request)
PD>можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид

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

PD>Internet(XML request)
PD>а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.

PD>Но я уже слышу топот копыт. Ко мне стремительно приближается сферический конь в вакууме и я начинаю ощущать вокруг себя ауру безвоздушного пространства. Так что развивать это направление не буду.

PD>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?

Вот честно, не догадался. Ослабел на догадки после разбора и многократного переанализа.

Поел и решил добавить — насчет АПИ. Приведу пример из своей практики.

Делал я в свое время одну БД. Ну БД — слишком громко сказано, некий файл со структурой, которую я точно так и не смог определить. Что-то вроде дерева списков подсписков множеств

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

. Ну и еще известная всем моя склонность к оптимизации — я решил, что должен сделать в 2-3 раза быстрее, чем мне заказано. Могу ведь — почему не сделать ?

У этого хозяйства был вполне классический АПИ в виде одной-единственной функции, которой подавался указатель на структуру запроса и она возвращала данные ответа (в mmf), по которым можно было итерировать. В общем, ничего особенного. Классика.

Для тестирования этой классики мы соорудили клиента, который принимал текстовую строку в стиле SELECT-WHERE (в действительности синтаксис был иной) и тестировали всласть

Строку эту набирали вручную.

А вот теперь представь, что этот клиент (C) — лишь часть клиента, а надклиент (SC) эту строку как-то сооружает и этому C передает. Так вот, эта строка и будет АПИ этого C! У C есть АПИ для SC, и он заключается в текстовой строке! Мы такое не сделали, просто потому, что не надо было. А вот сейчас я как раз такого SC и написал, заказчик его тестирует. Но это уже другая задача.

Это не сферический конь в вакууме, а часть проекта, работающего на сотнях компьютеров уже 5-6 лет.

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

PD>>О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ?

ГВ>Боже мой! На этот вопрос давать "общий" ответ нельзя по определению. Всё решается на месте.

+1

ГВ>Павел, не ведись ты на общую вакханалию. Приложения всегда были и будут именно "просто" приложениями.

+1. А я что, не это же говорю ?

ГВ>Значится так... Linux народился на свет в 1991. Windows NT обрела папочку в 1988:

ГВ>Иными словами, аргументы из серии "Linux логичнее, чем Windows и Windows его боится и боялся отродясь" отправляются в лес жарить шашлык.

Гена, ты что говоришь ? Я разве сравнивал логичность Windows NT и Unix ? Мне только не хватало на эту тему выступить

. Я сравнивал Unix и Windows 9x, вот и все.

>Более чем уверен, что на момент выпуска NT (см. также материалы по теме OS/2) её разработчики про Linux, может, и знали чего, но так... Мало ли курьёзов в IT? Студенты, они такие — всё время вселенную потрясти пытаются, ну и пущай себе пытаются.

Да при чем тут Линукс ? Я просто хотел сказать, что продолжай они тупиковую 9x и не начни NT, их бы в конечном счете кто-нибудь съел. Не Линукс, так кто-то иной.

ГВ>С другой стороны, DOS, в принципе, это не более, чем монитор прерываний, а не операционная система. Отсюда мораль: она не могла стать ни современной операционной системой, ни какой бы то ни было существенной ОС вообще. Вся причина её успеха в том, что MS вовремя подсуетилась с заказом от IBM. Более того, согласись, забавно, что "современная ОС" по каким-то мистическим причинам недалеко ушла от ОС 70-х. Я имею в виду Unix. Тогда как куда как более моладая DOS уже предана повсеместному порицанию.

Ну тут я не со всем соглашусь. DOS все же действительно не имела многого из того. что ОС должна иметь, да ты и сам с этим согласен. Так что их сравнивать некорректно.

ГВ>Павел, да плюнь ты вообще на "классы" в частности и на "ООП" вообще. Чем дальше в лес, тем надёжнее я, например, прихожу к выводу, что "объектная ориентация" это очень большая подколка. Попросту говоря — тупиковая ветвь развития.

Ох, не знаю... Может быть.

PD>>Internet(XML request)
PD>>а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.

PD>>Но я уже слышу топот копыт. Ко мне стремительно приближается сферический конь в вакууме и я начинаю ощущать вокруг себя ауру безвоздушного пространства. Так что развивать это направление не буду.

PD>>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?

ГВ>Вот честно, не догадался. Ослабел на догадки после разбора и многократного переанализа.

DNS. Запрос в Интернет вообще. Неизвестно куда.

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

PD>DNS. Запрос в Интернет вообще. Неизвестно куда.

Почему это неизвестно куда? По вполне известному адресу(-ам).

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

PD>По мелочам отвечу. С чем согласен — просто опустил.

Угу.

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

ГВ>>Болт! Сайт в данном случае ничего не экспонирует. Окромя допустимых аргуметов "type" и "color".

PD>Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект. Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ? Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?

Да, я считаю, что аналогия не совсем корректна. Это существенный вопрос, возьму таймаут где-то на сутки. Об остальном — ниже.

>>Речи о ынутренней структуре тут и быть не может.

PD>Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ? product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.

Ошибочна тут исходная посылка — представление сайта в виде набора агрегатов и приклеивание к этому представлению поисковых запросов.

ГВ>>Погоди. Не надо натягивать презерватив на покрышку. Это и не класс, и не методы. Это всего лишь поисковые запросы.

PD>Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй.

Тема N2 для таймаута. С ООП вообще всё неоднозначно.

PD>Я думаю, ты понимаешь, что я не предлагаю садиться и эти классы писать. Это только модель для рассуждений. Но если она неверна — объясни, почему.

Да, это я понимаю.

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

PD>И что ? А для обычных, классических функций всегда гарантировано сохранение результата во времени ? Не говоря уж о рандомах, но возьми, к примеру, алгоритмы оптимизации. Изменили метод оптимизации — получили малость другой результат. Я уж не говорю, скажем, о функциях вывода на печать — тут очень многое может измениться.

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

Ни в коем случае не собираюсь этого доказывать. Они не расставляют, а следовательно и не учитывают приоритеты параметров запросов. Здесь вопрос именно в том, на какую модель мы хотим натянуть описание запросов.

ГВ>>Э-э-э, батенька! Так "произвольного" или "для данной цели"?

PD>Не пойдет. Именно произвольного (т.е не обязательно броузера, а что захотим, то и напишем, и какими средствами захотим , такими и напишем, и будет он десктопным или нет — как захотим), но для данной цели. [...] Вот и все, что я хотел здесь сказать.

O'K, понял.

PD>>>Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет
ГВ>>Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API.
PD>WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.

Я думаю, что проще предполагать, что ссылка на .aspx — это ссылка на элемент второстепенной структуры. В прочем, это тема N3 для того же таймаута.

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

Ладно, пока примем это допущение. Я просто хотел указать на то, что перетасовка семантики терминов может привести к нежелательным результатам.

PD>>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных.
ГВ>>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся!
PD>Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ?

Нет, разумеется. Просто это и в самом деле очень важно: упрощения должны быть корректными.

PD>>>Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.

ГВ>>Стойка обретает суровую стабильность...

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

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

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

WF>Почему это неизвестно куда? По вполне известному адресу(-ам).

Я отправляю запрос на разрешение имени — получить IP. Я не знаю, куда он пойдет. То, что он пойдет на мой DNS сервер — роли не играет, это константа, я всегда на один и тот же адрес посылаю. А дальше пусть Интернет (точнее, распредленная БД DNS) разбирается.

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

>>Более чем уверен, что на момент выпуска NT (см. также материалы по теме OS/2) её разработчики про Linux, может, и знали чего, но так... Мало ли курьёзов в IT? Студенты, они такие — всё время вселенную потрясти пытаются, ну и пущай себе пытаются.

PD>Да при чем тут Линукс ? Я просто хотел сказать, что продолжай они тупиковую 9x и не начни NT, их бы в конечном счете кто-нибудь съел. Не Линукс, так кто-то иной.

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

PD>>>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?

ГВ>>Вот честно, не догадался. Ослабел на догадки после разбора и многократного переанализа.

PD>DNS. Запрос в Интернет вообще. Неизвестно куда.

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

Timeout — on

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

На все, что ты пометил как тему для обдумывания — не отвечаю.

ГВ>Ошибочна тут исходная посылка — представление сайта в виде набора агрегатов и приклеивание к этому представлению поисковых запросов.

Ну во-первых, определение агрегата в студию

. Пока его нет — будем считать агрегат == класс в моем понимании. А насчет поисковых запросов попробую объяснить. На аналогии.

Вот представь себе DLL. Импорта нет. Но есть .pdb или .sym. Можно пытаться на этой основе вызывать функции. В общем, работает, пока не перекомпилировали.

А теперь допустим, что и .sym нет

Но вдруг стало известно (не важно откуда), что если управление передать по RVA 0x1234 и до этого в стек заслать пару int, то будет хороший результат — экран разрисуют серо-буро-малиновым. Эту информацию ты мне сообщил. Я ее записал.
А потом мне Вася Пупкин еще про аналогичный вызов сообщил. Если по RVA 0x2353 вызывать, предварительно заслав 3 int,то на экране сферического коня нарисуют.

И т.д. И т.п. И все это я собрал. А еще я научился сам такие пробы делать и их собирать.

И вот теперь я FAQ делаю. Чтобы серо-буро-малиновым — по 0x1234. Чтобы коня — 0x2353. И т.д.

А ты мне запрос делаешь — как, мол, коня нарисовать ? А я тебе в ответ — 0x2353.

Дурацким делом все мы, конечно, занимались, но разве от этого DLL не перестала быть некоторым АПИ ?

PD>>Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!

ГВ>Ни в коем случае не собираюсь этого доказывать. Они не расставляют, а следовательно и не учитывают приоритеты параметров запросов. Здесь вопрос именно в том, на какую модель мы хотим натянуть описание запросов.

Именно! Обычная модель — все же AND (ну не совсем). Я хочу — иерархию.

ГВ>Я думаю, что проще предполагать, что ссылка на .aspx — это ссылка на элемент второстепенной структуры. В прочем, это тема N3 для того же таймаута.

А все же — что тут делает .aspx ? Зачем мне, пользователю, знать, кто там скрывается ? К тому же и врут безбожно. Синклер приводил пример с .php, за которвм может что угодно скрываться. Я могу еще пример с .html привести — за ним такой Tapestry слой может стоять вместо чистого HTML, что не дай боже. А зачем мне все это знать ? Зачем вы мне эту структуру показали ? Чтобы я вместо asmx asm набрал и удивлялся, с чего это я не получил в ответ mov eax, 0 ?

PD>>>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных.
ГВ>>>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся!
PD>>Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ?

ГВ>Нет, разумеется. Просто это и в самом деле очень важно: упрощения должны быть корректными.

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

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

ГВ>Совершенно согласен про эффект второго порядка. Не согласен с тем, что интернет можно рассматривать как иерархическую БД.

Я разве такое говорил ? Но сетевая модель на порядок сложнее. В конце концов, и реляционные БД есть тоже упрощение — нет в реальности никаких реляционных схем, там скорее иерархия или сеть. Однако же работают.

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

Нет, конечно.

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

ГВ>>Стойка обретает суровую стабильность...

PD>Зря ты эту стойку принял. Такое моделирование совершенно обычно в научных исследованиях.

Только вот разработка архитектуры ПО это исключительно инженерная деятельность.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>

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

AVK>Только вот разработка архитектуры ПО это исключительно инженерная деятельность.

То-то в Америке этим в основном университеты и занимались. ОС, к примеру, да мало ли что еще.

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

PD>Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект.
Ок. Что есть объект в твоем понимании? Некая сущность обладающая identity и state, который меняется под воздействием приходящих messages в cоответствии с некоторым behavior этого объекта, так?
PD>Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ?
Не то чтобы неверно. Пока что ты не указал никакого критерия относительно того, что ты считаешь подобъектом объекта.
PD> Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?
Так, только что никакой речи о классах не было. Я отношу себя не к ученым, а к тупым инженерам, поэтому меня всегда настораживает, когда термины начинают произвольно взаимозаменяться, типа класс<->объект, формат<->протокол, и так далее.
PD>Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ?
Гм. Следует ли из этого, что a.com/product.html?productId=188 — это другой подобъект сайта a.com?
Является ли он подобъектом объекта a.com/product.html
PD> product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.
Ну вот, опять класс.
PD>Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй.
PD>Я думаю, ты понимаешь, что я не предлагаю садиться и эти классы писать. Это только модель для рассуждений. Но если она неверна — объясни, почему.
Ну, например потому, что класс подразумевает множество объектов.
Предположим, ты предлагаешь рассматривать HTTP-реквесты как вызовы методов некоторого объекта. Ок, не проблема.
Не очень правда понятно, каким образом ты разделяешь объекты и методы.
Вот a.com/product.html?productId=188 — это что? Вызов a_com.product(188), или a_com.product.productId(188)?
PD>И что ? А для обычных, классических функций всегда гарантировано сохранение результата во времени ?
Если мы говорим о вызовах методов в распределенной системе, то для достижения успеха крайне полезно с самого начала озаботиться разделением методов на консервативные, идемпотентные, и все остальные. Потому что от этого крайне зависят возможности оптимизации в среде, где накладные расходы на вызов как правило превышают оные на его обработку.
PD>Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!
Гм. Я не очень понимаю, что такое "приоритет входных параметров запроса". Ты про какой запрос?

PD>Не пойдет. Именно произвольного (т.е не обязательно броузера, а что захотим, то и напишем, и какими средствами захотим , такими и напишем, и будет он десктопным или нет — как захотим), но для данной цели. Если я писал в свое время такой клиент для задач оптимизации финансовых расчетов (реализуемых сервисом), то для задач предсказания погоды он не пойдет. Но мы этот клиент делали как десктопное приложение (для отладки), как код, вызываемый их Excel и т.д.

PD>А вот если бы этот сервис вернул мне javascript, то пришлось бы либо исполнять это только из броузера, либо писать свой интерпретатор javascript и надеяться, что в ответе будет только часть, относящаяся к задаче, а не window.open(...), в противном случае придется свой броузер писать. Вот и все, что я хотел здесь сказать.
Ну, именно поэтому сервисов, которые бы возвращали джаваскрипт (в том виде, в котором ты его здесь понимаешь), в природе не существует. Есть сервисы, которые возвращают JSON, но в нем не будет привязки к environment браузера, а парсеры JSON есть уже для всех популярных языков программирования.

А веб-приложения, которые ориентированы на исполнение в браузере, могут как раз исполняться в браузере. Что, впрочем, ничему не мешает. См. например Google AJAX Search API для сравнения с google.com.

PD>WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.
Экспонирование чего? Ссылка ничего не говорит о структуре. Со ссылкой можно сделать только одно: разыменовать. Есть желание расширить модель и придать некую иерархическую семантику интернету? Ок, можно попробовать и так. Что будет листьями этого дерева?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

AVK>>Только вот разработка архитектуры ПО это исключительно инженерная деятельность.

PD>То-то в Америке этим в основном университеты и занимались.

И что? Университеты, тем более технологгические, тем более в штатах, вполне могут заниматься инженерно-конструкторской деятельностью.

... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>

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

Собрал здесь то, над чем подумал дополнительно. Мои возражения оказались не во всём состоятельными.

PD>Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект. Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ? Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?

Прежде всего, что вот это:

com.a.html.product(type=elephant,color=rose)

вовсе не внутренняя структура сайта. Это некоторый URL и только. Про внутреннюю структуру мы ничего не знаем, поскольку URL попадает на соответствующий сайт и там уже может быть трансформирован во всё, что угодно.

PD>Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ? product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.

Не забывай, что этот URL (a.com/product.html) выдан нам самим этим сайтом, соответственно, он может воообще никак не соотноситься с внутренней структурой самого сайта. Вот в таком вот интересном виде разработчики договорились выдавать ссылки на какие-то элементы своей программы, открытой внешнему миру под маской web-сервера.

Безусловно, мы сами можем интерпретировать текст этого URL как набор некоторых объектов. Скажем, объектов типа CDomainName, CSiteDirectory, CSitePage, etc. Но это уже наше личное, внутреннее дело. К внутренней структуре сайта сие никакого отношения не имеет. Всё, что мы знаем об этом сайте, это то, что если ему послать вот этот URL:

com.a.html.product(type=elephant,color=rose)

то обратно нам раньше или позже прилетит какое-нибудь:

<html>Бамбарбиа! Кергуду!</html>

PD>Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй.

Можно. Можно рассмотреть поисковый URL как вызов метода экземпляра некоторого класса. Я просто смысла в этом не вижу. Получается, что есть класс Internet с методом GetData(url), или класс TGoogle с аналогичным методом и т.п. Ну да, некая обобщённая модель, которая вполне может быть реализована на клиенте... А дальше что?

PD>>>Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет
ГВ>>Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API.
PD>WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.

Не совсем так. WSDL-описуемый вызов, как и URL — птицы одного полёта. И тот и другой можно абстрагировать от внутренней структуры сайта. Web-сервер может весь URL дополнительно парсить/анализировать/перенаправлять, и тот факт, что там указана какая-то mypage.jsp, не может быть гарантией того, что такая страница существует в действительности в виде отдельного .jsp-файла. Это вполне может быть, например, ключом к каким-то внутренним базам данных, скрытым web-сервером. На вскидку не скажу, какие серверы умеют именно так делать, но ничего невозможного тут не вижу. Соответственно, ссылка — это не более, чем навигационное приспособление, т.е., артефакт уровня репрезентации. Как она в действительности интерпретируется сайтом — отдельный вопрос.

Мы достатчно уверенно можем сказать только то, что например, в таком URL: http://www.a.com/mypages/mypage.htm?a=1&b=2 только "a.com" представляет собой имя некоторого узла, которое превратится DNS-ом в некоторый IP-адрес. Но и всё. Дальше — ведомство уже этого самого узла.

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

ГВ>>Ошибочна тут исходная посылка — представление сайта в виде набора агрегатов и приклеивание к этому представлению поисковых запросов.
PD>Ну во-первых, определение агрегата в студию

. Пока его нет — будем считать агрегат == класс в моем понимании.

Встречное пожелание: что такое класс в твоём понимании?

PD>А насчет поисковых запросов попробую объяснить. На аналогии.

PD>Вот представь себе DLL. Импорта нет. [...]
PD>А ты мне запрос делаешь — как, мол, коня нарисовать ? А я тебе в ответ — 0x2353.
PD>Дурацким делом все мы, конечно, занимались, но разве от этого DLL не перестала быть некоторым АПИ ?

Ограниченный контекст... Всем всё заранее известно... Осталось только найти точку входа в известно, какую функцию. Что-то я не понимаю, что ты хочешь до меня донести.

PD>>>Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!
ГВ>>Ни в коем случае не собираюсь этого доказывать. Они не расставляют, а следовательно и не учитывают приоритеты параметров запросов. Здесь вопрос именно в том, на какую модель мы хотим натянуть описание запросов.
PD>Именно! Обычная модель — все же AND (ну не совсем). Я хочу — иерархию.

Понятно.

ГВ>>Я думаю, что проще предполагать, что ссылка на .aspx — это ссылка на элемент второстепенной структуры. В прочем, это тема N3 для того же таймаута.

PD>А все же — что тут делает .aspx ? Зачем мне, пользователю, знать, кто там скрывается ? К тому же и врут безбожно. Синклер приводил пример с .php, за которвм может что угодно скрываться. Я могу еще пример с .html привести — за ним такой Tapestry слой может стоять вместо чистого HTML, что не дай боже. А зачем мне все это знать ? Зачем вы мне эту структуру показали ? Чтобы я вместо asmx asm набрал и удивлялся, с чего это я не получил в ответ mov eax, 0 ?

Так ты сам всё время говоришь про какую-то "внутреннюю структуру" сайта. А в URL в общем случае её нет ни разу. Не обязан URL отражать внутреннюю структуру, следовательно, нельзя и апеллировать к этому. Может, но не обязан.

PD>>>>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных.
ГВ>>>>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся!
PD>>>Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ?

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

Ага. Складываем 2 и 2. Ты хочешь любой сайт приводить к некоей иерархической интерпретации, так? Или к набору таких интерпретаций. Верно? Почему говорю "хочешь", — потому что никакой имманентно присущей им структуры у сайтов нет. Это может быть вообще плоская как доска таблица SQL, где лежит содержимое всех страниц, доступных извне через систему разделов, подразделов и т.п.

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

PD>Кажется, я наконец-то сам понял, чего я добиваюсь

Кажется, и я наконец-то понял, чего ты добиваешься. Ты хочешь искать информацию по её семантике, правильно?

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

PD>А вот теперь представь, что этот клиент (C) — лишь часть клиента, а надклиент (SC) эту строку как-то сооружает и этому C передает. Так вот, эта строка и будет АПИ этого C! У C есть АПИ для SC, и он заключается в текстовой строке! Мы такое не сделали, просто потому, что не надо было. А вот сейчас я как раз такого SC и написал, заказчик его тестирует. Но это уже другая задача.

Я так думаю, что правила, по которым SC сооружает строку для C вполне точно определены, потому здесь нет ничего необычного. Это вопрос кодирования информации, ничего более.

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

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

PD>>Кажется, я наконец-то сам понял, чего я добиваюсь

ГВ>Кажется, и я наконец-то понял, чего ты добиваешься. Ты хочешь искать информацию по её семантике, правильно?

Ответ здесь на все твои постинги.

Искать информацию по семантике ? Хорошо бы, но вряд ли получится. Потому что семантика за кадром, как я уже писал, и, как ты верно отметил, есть просто соглашение. Почему tiff — это обычно графический файл ? Потому что большинство с этим согласилось. Это не формализуемо. Почему ++ — это инкремент ? Тоже согласились. Можно вполне язык предложить, где это иначе делается, да и предлагать не нало — Inc в Паскале. Ничего тут ИМХО сделать нельзя.

А вот с иерархичными запросами — можно. Более того, вполне реально. Но сначала отвечу на твои замечания

ГВ>Прежде всего, что вот это:

com.a.html.product(type=elephant,color=rose)

вовсе не внутренняя структура сайта. Это некоторый URL и только. Про внутреннюю структуру мы ничего не знаем, поскольку URL попадает на соответствующий сайт и там уже может быть трансформирован во всё, что угодно.

Может. Но далеко не всегда это делается. Точнее, чаще всего не делается. Обращение по линку

a.com/goods/product.html?type=elephant,color=rose

есть все же обращение к странице product.html из виртуального каталога goods. Да, оно может быть потом трансформировано во что угодно, но в большинстве случаев при отсутствии вирт. каталога goods ты получишь либо 404, либо редирект куда-нибудь, может, и разумный, может, на улучшенный 404.

А вот с тем, что сайт не есть иерархическая структура — не согласен. В точном понимании он, конечно, не есть иерархия, но все же остовное дерево в нем обычно есть. Это следует просто из того, что во внутренней структуре сайта часто имеется parent для каждой страницы. Я не утверждаю, что всегда, но чаще всего все же есть. Иерархичность просто следует из логики представления информации. Есть компания, у нее есть товары, услуги, документы, товары в свою очередь подразделяются на ..., услуги на... и т.д. Да, конечно, потом это сто раз перевязано гиперлинками, но основа сохраняется.

Кстати, если эту компанию как таковую рассмотреть, то это очень хорошо заметно. Есть руководство, есть отдел кадров, есть бухгалтерия, отдел производства, отдел торговли и т.д. Конечно, все это переплетено массой горизонтальных связей, формальных и неформальных, но это не отменяет базовой структуры.

Вернусь сюда

a.com/goods/product.html?type=elephant,color=rose

Ну а если goods решено переименовать в products ? Или просто пользователь неправильно набрал линк

a.com/good/product.html?type=elephant,color=rose

Обычно из этого следует в той или иной форме 404. Ты можешь мне 100 раз говорить, что внутренняя структура сайта в действительности может быть скрытой и все эти линки поведут на

a.com/tra-la-la/tru-tu-tu.html?type=elephant,color=rose

где разберутся со всем этим. Могут. Но нет этого.

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

. Но если она решила расширить ассортимент рогов, добавив рог носорога, то дерево сильно не пострадает.

А дерево это уже есть, между прочим. Если со страницами ассоциированы ключевые слова, то они и образуют это дерево. Никакого другого не надо. Но сейчас поиск идет по ключевым словам обычно в пределах страниц. Надо этот поиск сделать иерархичным.

Вот смотри

http://a.com XML (я оставлю XML, но понимай что хочешь под ним).

На XML описывается запрос. Он иерархинчный, то есть мне в первую очередь нужен слон, а уж потом розовый, при отсутствии розового я готов на любого слона, а при отсутствии слона в запросе есть ветка else, которая выдаст мне мамонта, если он есть.

Этот запрос парсится в соответствии со структурой сайта, описанной деревом ключевых слов. Вместо того, чтобы

a.com/goods/product.html?type=elephant,color=rose

обращаться к вирт. каталогу goods, идет сравнение дерева запроса с деревом сайта. В запросе, скажем, присутствует слово "товар" Именно так, по русски. На верхнем уровне сайта идет разбор этого запроса с привлечением ключевых слов, которых может быть довольно много , синонимов в некотором смысле — products, товар, товары, goods, prod (да-да, почему бы и не сокращения). И если в запросе присутствует "товар", то направление дальнейшего прохода дерева сайта определилось. И если prod — тоже, или goods. Дальше на следующем уровне в запросе есть "elephant", а может , "слон", а может, "хоботное". В любом случае соотнесение произведено.

В результате возможно одно из двух. Либо запрос реализуется точно, и тогда мы попадаем на Response для продаваемого розового слона. Либо он точно не реализуется, тогда начинает работать приближенный поиск, который, впрочем, в отличие от полнотекстового не вернет мне ни розовое небо, ни розовые обои. Потому что тут иерархия, а не AND, а на верхнем уровне иерархии розового нет. Вот если бы это был сайт для живописцев, то может быть, выше было бы розовое, а потом уж что.

Если запрос был успешным и точным, его можно сохранить. В дальнейшем, если его повторить, возможно одно из 3. Либо он останется точным и приведет к точному Response, хотя , возможно, совсем другому, так как изменился ассортимент розовых слонов и было решено их из товаров отправить в раздел "животные". Это изменения во внутренней структуре, они никого не касаются. Либо запрос перестал быть точным (фирма все еще торгует слонами, но только не розовыми), в этом случае возвращается приближенный Response. Либо запрос реализовать совсем нельзя, так как фирма перепрофилировалась не реактивные лайнеры. Ну, тут ничего не поделаешь.

Кстати, если вернуться к "живой" компании, то здесь может быть то же самое. Приходит письмо от неизвестной до сих пор личности (если известной, алгоритм может быть иной). Его кладут на стол директору, который отправляет его кому-то из заместителей. По каким критериям ? Да по списку ключевых слов. Читать ему это письмо некогда, поэтому он пробегает его по диагонали и видит там слова, на основании которых решает, что это в компетенции заместителя по маркетингу. Тот, в свою очередь, сделает то же, отправив этот запрос помощнику по копытам. И т.д.

Такой иерархичный поиск, в отличие от полнотекстового, мало того, что более конкретен, но еще и более "машинизируем". Его можно автоматически генерировать. Например, обнаружен сайт, новый. Обшарим его , начиная с home page, потом устроим , например, анализ частот встречаемых слов и определим предметную область (нет-нет, никакой семантики пока, просто набор наиболее часто встречаемых терминов безотносительно к смыслу). Теперь этот сайт можно "попытать". На основе этого набора терминов шлем ему сгенерированные иерархические запросы. Например, отобрали мы 2 термина — слон и розовый. Шлем ему запрос со словом слон наверху, а розовый — ниже. Он дает Response, точный (можно, кстати, некий Confidence завести), а поэтому мы этот запрос сохраняем. На запрос, в котором выше розовый, а ниже — слон, Response будет нулевой, а поэтому мы его просто отбросим. И т.д. В результате мы имеем набор запросов, на которые этот сайт дает вразумительные ответы. Если теперь это все проанализировать, то в итоге может получиться Google2

, который будет по некоторому запросу (его, конечно, придется иерархичным делать пользователю или его софту) подбирать более или менее похожие запросы их возвращать. Вместо 100,000 ссылок.

Резюмируя, скажу следующее. Делая запрос к сайту, я вообще не интересуюсь его внутренней структурой. Рассматривай ее как хочешь, хоть как истину, хоть как сокрытие и перенаправление, мне она все равно не нужна. Меня не интересует, php там, aspx или html. Меня не интересует набор каталогов в строке URL, что бы они не означали. Это вообще не мое дело. Меня интересует только запрос и ответ. А структура запроса должна быть приближена к его "естественной" структуре. Формального определения последней я не дам

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

Тогда получается, что в целом всё выглядит достаточно просто. Поисковый запрос сопоставляется с иерархическим "справочником" ключевых слов, котрый уже определяет множества страниц, содержимое которых следует отсматривать. Проблем я вижу две:

1. Построение этого самого справочника.
2. Синтаксис языка запросов, он получается слегка нетривиальным.

По первому пункту.

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

По второму пункту ответ кажется простым. Можно использовать тот же синтаксис S-expression, тогда, например, запрос на поиск розового слона с предпочтением слонов, а не "розовости" может выглядеть так:

(elephant (rose))

В принципе, ничего необыкновенного.

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

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

ГВ>Тогда получается, что в целом всё выглядит достаточно просто. Поисковый запрос сопоставляется с иерархическим "справочником" ключевых слов, котрый уже определяет множества страниц, содержимое которых следует отсматривать. Проблем я вижу две:

ГВ>1. Построение этого самого справочника.
ГВ>2. Синтаксис языка запросов, он получается слегка нетривиальным.

ГВ>По первому пункту.

ГВ>Насколько я понял, ты предлагаешь воспользоваться некоей разновидностью "естественной" упорядоченности данных сайта, определяемой, например по длине "пути" в URL. Соответственно, ключевые слова, встречающиеся в "верхних" страницах имеют, в некотором смысле, больший вес, чем такие же слова в "нижних".

Не совсем так просто. Тут в принципе можно любую логику реализовать. Например, при неудачном точном поиске устроить приближенный или вообще перейти к другому разделу. Кстати, при этом (сейчас понял) необязательно сайт в качестве дерева рассматривать. Можно и как граф, то есть в истинном виде.

>Оставлю пока за скобками вопрос о надёжности такого метода, перейду к главному. Здесь есть очень большая проблема определения словаря этих ключевых слов. Что считать ключевыми словами? Нужно ли для этого вводить какой-то предопределённый словарь или воспользоваться каким-то ещё формальными критериями выделения ключевых слов из содержимого сайта?

Только вручную. Эта структура должна просто создаваться разработчиком сайта и наполняться по мере надобности. Да, впрочем, эти ключевые слова и так есть , так они и вводятся. Сам не раз в такой разработке участвовал.

А иначе — мы опять к проблеме синтаксис — семантика перейдем.

ГВ>По второму пункту ответ кажется простым. Можно использовать тот же синтаксис S-expression, тогда, например, запрос на поиск розового слона с предпочтением слонов, а не "розовости" может выглядеть так:

(elephant (rose))

ГВ>В принципе, ничего необыкновенного.

Ничего необыкновенного, согласен.

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

Уф-ф-ф!

ГВ>>Насколько я понял, ты предлагаешь воспользоваться некоей разновидностью "естественной" упорядоченности данных сайта, определяемой, например по длине "пути" в URL. Соответственно, ключевые слова, встречающиеся в "верхних" страницах имеют, в некотором смысле, больший вес, чем такие же слова в "нижних".

PD>Не совсем так просто. Тут в принципе можно любую логику реализовать. Например, при неудачном точном поиске устроить приближенный или вообще перейти к другому разделу. Кстати, при этом (сейчас понял) необязательно сайт в качестве дерева рассматривать. Можно и как граф, то есть в истинном виде.

Ну да, структура сайта, — это лишь некоторая предварительная структура. Её можно и совсем проигнорировать.

>>Что считать ключевыми словами? Нужно ли для этого вводить какой-то предопределённый словарь или воспользоваться каким-то ещё формальными критериями выделения ключевых слов из содержимого сайта?
PD>Только вручную. Эта структура должна просто создаваться разработчиком сайта и наполняться по мере надобности. Да, впрочем, эти ключевые слова и так есть , так они и вводятся. Сам не раз в такой разработке участвовал.
PD>А иначе — мы опять к проблеме синтаксис — семантика перейдем.

Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе.

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

ГВ>Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе.
О-о, пацаны, еще немного, и вы изобретете Full Text Search и очередную версию алгоритма оценки релевантности.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

ГВ>Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе.

Да хотя бы и без них для начала. Сделали бы хоть иерархию, а слова найдутся

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

ГВ>>Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе.
PD>Да хотя бы и без них для начала. Сделали бы хоть иерархию, а слова найдутся

Кто — сделал бы?

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

— Какие символы обозначают иерархию;
— Какие слова являются ключевыми.

Этим может заняться специальный комитет...

Иными словами, приехали к сугубо организационной задаче.

ГВ>Этим может заняться специальный комитет...

А вот и первый кандидат.

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

ГВ>В общем, чтобы не разводить лишний флейм, обозначу главную проблему такого подхода: масса народу должна договориться по таким вопросам:

ГВ>- Какие символы обозначают иерархию;
ГВ>- Какие слова являются ключевыми.

ГВ>Этим может заняться специальный комитет...

ГВ>Иными словами, приехали к сугубо организационной задаче.

А это с самого начала ясно было. Любое решение, изменяющее текущее положение дел, требует стандартизации и комитета

Ждем-с

ГВ>>В общем, чтобы не разводить лишний флейм, обозначу главную проблему такого подхода: масса народу должна договориться по таким вопросам:

ГВ>>- Какие символы обозначают иерархию;
ГВ>>- Какие слова являются ключевыми.

ГВ>>Этим может заняться специальный комитет...

ГВ>>Иными словами, приехали к сугубо организационной задаче.

PD>А это с самого начала ясно было. Любое решение, изменяющее текущее положение дел, требует стандартизации и комитета

PD>Ждем-с

А можно вопрос — зачем?

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>А можно вопрос — зачем?

Чтобы грамотно искать розовых слонов

M>>А можно вопрос — зачем?

PD>Чтобы грамотно искать розовых слонов

И все началось с неправильной предпосылки о том, что через HTTP можно отсылать только запросы типа GET product=elephant&color=pink ?

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>А можно вопрос — зачем?

Вот тебе простой пример

Ищу на Гугле себя, любимого

http://www.google.ru/search?complete=1&hl=ru&newwindow=1&q=%D0%94%D0%B2%D0%BE%D1%80%D0%BA%D0%B8%D0%BD+%D0%9F%D0%B0%D0%B2%D0%B5%D0%BB+%D0%9B%D0%B0%D0%B7%D0%B0%D1%80%D0%B5%D0%B2%D0%B8%D1%87&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=-1&oq=

Получил примерно 1 240 . Многовато. Я хоть и личность известная, но не настолько

В начале , действительно, обо мне. А вот дальше

ПОБЕДИТЕЛИ — Солдаты Великой Войны | Зарубежье / Беларусь ...Дворкин Семен Абрамович. Дворник Василий Иванович ... Дейкун Василий Лазаревич. Дейкун Василий Сергеевич. Дейкун Григорий Петрович. Дейкун Лариса Тихоновна ...
www.pobediteli.ru/foreign/belarus/gomelskaya/d/dvo-del/index.html — 15k — Сохранено в кэше — Похожие страницы

Это не ко мне. Я хоть и не так молод, но в войне все же не участвовал

Фамильные интернет проекты и форумы. Список всех российских фамилий.... Беньковская Усейнов Дуляр Розенбаум Розина Красильщикова Дворкин Аладько ..... Лаврентиевич, Лазаревич, Львович, Леонович, Леонардович, Леонидович, ...
allfamilii.narod.ru/18.htm — 83k — Сохранено в кэше — Похожие страницы

И это не обо мне. Это вообще что-то не то.

Если думаешь, что дальше можно не смотреть — ошибаешься. После этого опять обо мне.

Информационные технологии / Информатика. Из этого документа следует...Автор: Дворкин Павел Лазаревич<dvorkin@math.omsu.omskreg.ru>. Дата: 12.09.2002 13:56 ... Дворкин Павел Лазаревич, 12.09.2002 13:56 ...
ap2004.alledu.ru/forum/317/342/2249/1 — 17k — Сохранено в кэше — Похожие страницы

А потом опять меня не касается

Светлана Сорокина: передачи, интервью, публикации. Personalia.Данилов Евгений Петрович Дашкова Полина Викторовна Дворкин Владимир Зиновьевич .... Рачевский Ефим Лазаревич Регент Татьяна Михайловна Резник Генри Маркович ...
tvoygolos.narod.ru/personae.htm — 74k — Сохранено в кэше — Похожие страницы

и т.д.

Дело в том. что Гугл ищет не иерархично, а просто по словам. Есть три слова — Дворкин Павел Лазаревич — показывает. Хотя Дворкин тут вовсе Владимир, Лазаревич — Ефим, а Павел, видимо, не показали.

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

точный поиск — только те страницы, для которых есть иерархия Дворкин — Павел — Лазаревич
неточный — еще и те, для которых Дворкин — Павел . Тоже неплохо, вернут те страницы, где мое отчество отсутствует. Может , я, может, не я

Но никаких Дворкиных Владимиров, и никаких Ефимов Лазаревичей!

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

M>И все началось с неправильной предпосылки о том, что через HTTP можно отсылать только запросы типа GET product=elephant&color=pink ?

Да шут с ней, с этой предпосылкой, правильная она или нет. Результат

http://www.rsdn.ru/forum/message/2909170.1.aspx

интереснее ИМХО.

А то, что начали с одного, а пришли к другому — так бывает

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

ГВ>>Иными словами, приехали к сугубо организационной задаче.
PD>А это с самого начала ясно было. Любое решение, изменяющее текущее положение дел, требует стандартизации и комитета

В данном случае требуется что-то вроде одного из многочисленных комитетов по согласованию форматов электронного документооборота (EDI). Аккурат тем же самым занимаются — согласуют какой код в каком случае что означает. Много согласуют, объёмисто...

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

Не понимаю я тут тебя, Павел.

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

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе.
S>О-о, пацаны, еще немного, и вы изобретете Full Text Search и очередную версию алгоритма оценки релевантности.
Или Gopher. Вот там всё как Павел хочет — жосткая структура, предопределенный контент-тайп.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Pavel Dvorkin, Вы писали:
M>>А можно вопрос — зачем?

PD>Ищу на Гугле себя, любимого
Открой для себя продвинутые операторы гуглового поиска.
http://www.google.ru/search?complete=1&hl=ru&newwindow=1&q=%22%D0%9F%D0%B0%D0%B2%D0%B5%D0%BB+%D0%9B%D0%B0%D0%B7%D0%B0%D1%80%D0%B5%D0%B2%D0%B8%D1%87%22+%D0%94%D0%B2%D0%BE%D1%80%D0%BA%D0%B8%D0%BD&lr=
И никаких Дворкиных Владимиров, и никаких Ефимов Лазаревичей!

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

M>>И все началось с неправильной предпосылки о том, что через HTTP можно отсылать только запросы типа GET product=elephant&color=pink ?

PD>Да шут с ней, с этой предпосылкой, правильная она или нет. Результат

PD>http://www.rsdn.ru/forum/message/2909170.1.aspx

PD>интереснее ИМХО.

PD>А то, что начали с одного, а пришли к другому — так бывает

Ничего в этом результате нет интересного, ИМХО.

ТО, что Гугл не предоставляет возможности уточнять запросы до последней буквы зю, это его, Гугла, проблемы.

http://clusty.com/search?input-form=clusty-simple&v%3Asources=webplus&query=pink+elephant — колонка слева уже позволяет отсортировать запрос

Проблема не в том, что якобы злой HTTP Или существующая модель не позволяют уточнять запросы. Проблема в том — а как позволить пользователю задать такой запрос? А дальше — дело техники. Рисуем формочку побольше и POST'ом отсылаем все заполненые поля куда надо.

А информация в общем случае не может быть сруктурирована. Потому что мн очень инетерсно посмотреть на решение задачи: вывести иерархию для "Дворкин Павел Лазаревич" в контексте "отзывы к отелю SuperHotel" в городе X в стране Y для любого из туритических и прочих сайтов.

А что делать с просто текстом типа "Я сегодня был на море"?

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
M>>>А можно вопрос — зачем?

PD>>Ищу на Гугле себя, любимого
S>Открой для себя продвинутые операторы гуглового поиска.
S>http://www.google.ru/search?complete=1&hl=ru&newwindow=1&q=%22%D0%9F%D0%B0%D0%B2%D0%B5%D0%BB+%D0%9B%D0%B0%D0%B7%D0%B0%D1%80%D0%B5%D0%B2%D0%B8%D1%87%22+%D0%94%D0%B2%D0%BE%D1%80%D0%BA%D0%B8%D0%BD&lr=
S>И никаких Дворкиных Владимиров, и никаких Ефимов Лазаревичей!

И просто Дворкин Павел тоже нет. Где без отчества.

А вот это есть

ap2004.alledu.ru/forum/317/342/2249/1 — 17k — Сохранено в кэше — Похожие страницы

Доказательство предыдущего материала. : Академия Общественной ...ДВОРКИН Наум Израилович 1906 Днепропетровск Не указано 1936 1 38.01.26 58 38.02.01 ..... РОЗЕНШТЕЙН Павел Лазаревич 1885 Одесская Киров 1936 1 38.04.07 КРПО ...

Все правильно — Павел Лазаревич тут есть, кто спорит. И Дворкин есть

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

M>А информация в общем случае не может быть сруктурирована. Потому что мн очень инетерсно посмотреть на решение задачи: вывести иерархию для "Дворкин Павел Лазаревич" в контексте "отзывы к отелю SuperHotel" в городе X в стране Y для любого из туритических и прочих сайтов.

Думаю, что все не так мрачно. Если речь идет о странице, посвященной мне, то иерархия так Дворкин Павел Лазаревич. Если это мой отзыв об отеле, то их может быть несколько

Дворкин — Павел — Лазаревич — SuperHotel
и
SuperHotel — Дворкин — Павел — Лазаревич

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

M>А что делать с просто текстом типа "Я сегодня был на море"?

А ничего. Поищи по Гуглу и ничего путного не найдешь, как ни делай запрос. И здесь тоже. Я не панацею предлагаю.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
M>>>А можно вопрос — зачем?

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

F>нашелся фан-клуб Дворкина

Так я и знал, что кто-то заметит.

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

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

Ну-с, здравствуй, семантическая сеть, как становой хребет иерархии синонимов.

M>>А информация в общем случае не может быть сруктурирована. Потому что мн очень инетерсно посмотреть на решение задачи: вывести иерархию для "Дворкин Павел Лазаревич" в контексте "отзывы к отелю SuperHotel" в городе X в стране Y для любого из туритических и прочих сайтов.

PD>Думаю, что все не так мрачно. Если речь идет о странице, посвященной мне, то иерархия так Дворкин Павел Лазаревич.

Почему? Почему не Павел Лазаревич Дворкин? Что делть с национальными правилами предоставления информации?

PD> Если это мой отзыв об отеле, то их может быть несколько

PD>Дворкин — Павел — Лазаревич — SuperHotel
PD>и
PD>SuperHotel — Дворкин — Павел — Лазаревич

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

Хорошо, как это распространяется на весь интернет? У всех сайтов структура разная.
Как это программировать для каждого сайта? Потому что структура сайта и/или дерева могут даже близко не соответствовать реальной структуре сайта.

M>>А что делать с просто текстом типа "Я сегодня был на море"?

PD>А ничего. Поищи по Гуглу и ничего путного не найдешь, как ни делай запрос. И здесь тоже. Я не панацею предлагаю.

Я тогда смысла вообще не понимаю

Информация в люом случае не структуризуема. А для структуризуемой давно есть микроформаты, которые, правда, пока особого распространения не получили.

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

PD>Так я и знал, что кто-то заметит.

Профи. Как ты плавно всех вывел на свою рекламу.

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Профи. Как ты плавно всех вывел на свою рекламу.

Чего не сделаешь для блага концессии

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

M>>>А информация в общем случае не может быть сруктурирована. Потому что мн очень инетерсно посмотреть на решение задачи: вывести иерархию для "Дворкин Павел Лазаревич" в контексте "отзывы к отелю SuperHotel" в городе X в стране Y для любого из туритических и прочих сайтов.

PD>>Думаю, что все не так мрачно. Если речь идет о странице, посвященной мне, то иерархия так Дворкин Павел Лазаревич.

M>Почему? Почему не Павел Лазаревич Дворкин?

Потому что фамилия важнее имени, а имя — отчества. Меня не интересуют все Павлы на свете.

>Что делть с национальными правилами предоставления информации?

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

PD>> Если это мой отзыв об отеле, то их может быть несколько

PD>>Дворкин — Павел — Лазаревич — SuperHotel
PD>>и
PD>>SuperHotel — Дворкин — Павел — Лазаревич

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

M>Хорошо, как это распространяется на весь интернет? У всех сайтов структура разная.

Структура одна. Граф с выделенным узлом (home page)

M>Как это программировать для каждого сайта? Потому что структура сайта и/или дерева могут даже близко не соответствовать реальной структуре сайта.

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

M>>>А что делать с просто текстом типа "Я сегодня был на море"?

PD>>А ничего. Поищи по Гуглу и ничего путного не найдешь, как ни делай запрос. И здесь тоже. Я не панацею предлагаю.

M>Я тогда смысла вообще не понимаю

Информация в люом случае не структуризуема. А для структуризуемой давно есть микроформаты, которые, правда, пока особого распространения не получили.

А ты вообще что хочешь получить на предмет поиска "Я сегодня был на море" ? Сформулируй хоть какой-нибудь запрос для Гугла как он есть сейчас.

PD>>>Думаю, что все не так мрачно. Если речь идет о странице, посвященной мне, то иерархия так Дворкин Павел Лазаревич.

M>>Почему? Почему не Павел Лазаревич Дворкин?

PD>Потому что фамилия важнее имени, а имя — отчества. Меня не интересуют все Павлы на свете.

Это справедливо только для русского языка

>>Что делть с национальными правилами предоставления информации?

PD>Сайт обычно делается либо на одном языке, либо отдельные части для разных языков.

Нет, отдельные части в виде собственно отдельных частей не делаются.

PD>На каждом — свое. Конкретных советов дать не могу, но, поскольку это дерево предлагается строить вручную, то наполнители сайта должны знать, что у них важнее

Об этом ниже, там где "про море"

M>>Хорошо, как это распространяется на весь интернет? У всех сайтов структура разная.

PD>Структура одна. Граф с выделенным узлом (home page)

Зато граф очень разный

Причем точек входа может быть несколько, и каждая из этих точек может быть равнозначной

M>>Как это программировать для каждого сайта? Потому что структура сайта и/или дерева могут даже близко не соответствовать реальной структуре сайта.

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

Какого из графов? Как узнать, что

— Павел — Дворкин — отель
важнее, чем
— отель — Павел — Дворкин

Что делать с циклическими ссылками? Или равнозначными путями?

Для какого-нить last.fm путь

Bjork (певица) -> Mamut (пользователь) -> Glory Box (песня) -> Portishead(испольнитель) -> Jaropolk (пользователь)

не менее важен, чем то же, но в другую сторону. Или то же, но не зарагивая песни. Или то же, но не затрагивая исполнителей.

Вообще для ресурса вроде last.fm понятие "граф, начинающийся от home page" смысла, как такового, не имеет, потому что для него любая точка входа равнозначна.

M>>>>А что делать с просто текстом типа "Я сегодня был на море"?

PD>>>А ничего. Поищи по Гуглу и ничего путного не найдешь, как ни делай запрос. И здесь тоже. Я не панацею предлагаю.

M>>Я тогда смысла вообще не понимаю

Информация в люом случае не структуризуема. А для структуризуемой давно есть микроформаты, которые, правда, пока особого распространения не получили.

PD>А ты вообще что хочешь получить на предмет поиска "Я сегодня был на море" ? Сформулируй хоть какой-нибудь запрос для Гугла как он есть сейчас.

Хочу дешевый отель в турции, в анталии, с описанием. Под "описание" попадет и вот это и вот это и вообще чье-то описание в стиле "были на море". Как тот же ЖЖ сможет выдать на это иерархическую структуру? Как ЖЖ вообще сможет выавать хоть какую-то иерархическую структуру?

А с гуглем уже сейчас можно попытаться это найти

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

PD>>Потому что фамилия важнее имени, а имя — отчества. Меня не интересуют все Павлы на свете.

M>Это справедливо только для русского языка

Не думаю. Сказав Nickson, мы тем самым уже установили ассоциацию (в уме) с президентом США. Сказав "Richard" — мы не установили.

>>>Что делть с национальными правилами предоставления информации?

PD>>Сайт обычно делается либо на одном языке, либо отдельные части для разных языков.

M>Нет, отдельные части в виде собственно отдельных частей не делаются.

Собственно или не собственно, но страниц на двух языках одновременно я не видел.

PD>>Структура одна. Граф с выделенным узлом (home page)

M>Зато граф очень разный

Причем точек входа может быть несколько, и каждая из этих точек может быть равнозначной

Это не принципиально. В крайнем случае я готов на несколько несвязных графов с выделенной вершиной у каждого.

M>Какого из графов? Как узнать, что

M>- Павел — Дворкин — отель
M>важнее, чем
M>- отель — Павел — Дворкин

Никак. Я еще раз говорю — это вручную наполнители сайта должны решить. Если сайт по отелям, то важнее отель, потому что мои ФИО — это отзыв об отеле. А вот если я — владелец сети отелей

— то важнее ФИО.

M>Что делать с циклическими ссылками? Или равнозначными путями?

Ну ты от меня многого хочешь. Алгоритмы на графах есть, и обход возможен по-разному. А дать прописи немедленно я не хочу и не могу.

M>Для какого-нить last.fm путь
M>

Bjork (певица) -> Mamut (пользователь) -> Glory Box (песня) -> Portishead(испольнитель) -> Jaropolk (пользователь)

M>не менее важен, чем то же, но в другую сторону. Или то же, но не зарагивая песни. Или то же, но не затрагивая исполнителей.

M>Вообще для ресурса вроде last.fm понятие "граф, начинающийся от home page" смысла, как такового, не имеет, потому что для него любая точка входа равнозначна.

M>>>>>А что делать с просто текстом типа "Я сегодня был на море"?

PD>>>>А ничего. Поищи по Гуглу и ничего путного не найдешь, как ни делай запрос. И здесь тоже. Я не панацею предлагаю.

M>>>Я тогда смысла вообще не понимаю

Информация в люом случае не структуризуема. А для структуризуемой давно есть микроформаты, которые, правда, пока особого распространения не получили.

PD>>А ты вообще что хочешь получить на предмет поиска "Я сегодня был на море" ? Сформулируй хоть какой-нибудь запрос для Гугла как он есть сейчас.

M>Хочу дешевый отель в турции, в анталии, с описанием. Под "описание" попадет и вот это и вот это и вообще чье-то описание в стиле "были на море". Как тот же ЖЖ сможет выдать на это иерархическую структуру? Как ЖЖ вообще сможет выавать хоть какую-то иерархическую структуру?

M>А с гуглем уже сейчас можно попытаться это найти

А я вообще-то Гугл не предлагаю закрыть

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

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

PD>>>Потому что фамилия важнее имени, а имя — отчества. Меня не интересуют все Павлы на свете.

M>>Это справедливо только для русского языка

PD>Не думаю. Сказав Nickson, мы тем самым уже установили ассоциацию (в уме) с президентом США. Сказав "Richard" — мы не установили.

ИМХО, сказав Nickson, мы сказали только Nickson. Если мы хотим декларировать ассоциацию с президентом, то мы скажем Nickson, president.

PD>Никак. Я еще раз говорю — это вручную наполнители сайта должны решить. Если сайт по отелям, то важнее отель, потому что мои ФИО — это отзыв об отеле. А вот если я — владелец сети отелей

— то важнее ФИО.

А если ты владелец и пытаешься отозваться об отеле конкурентов?

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

ГВ>ИМХО, сказав Nickson, мы сказали только Nickson. Если мы хотим декларировать ассоциацию с президентом, то мы скажем Nickson, president.

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

PD>>Никак. Я еще раз говорю — это вручную наполнители сайта должны решить. Если сайт по отелям, то важнее отель, потому что мои ФИО — это отзыв об отеле. А вот если я — владелец сети отелей

— то важнее ФИО.

ГВ>А если ты владелец и пытаешься отозваться об отеле конкурентов?

Я согласен, не все так просто. Но вообще-то если рассматривать сайт не как дерево, а как сеть, то возможны пути обоих видов.

M>>Это справедливо только для русского языка

PD>Не думаю. Сказав Nickson, мы тем самым уже установили ассоциацию (в уме) с президентом США. Сказав "Richard" — мы не установили.

Я, сказав Nickson, устанавливаю ассоциацию с кем угодно, только не с Никсоном

Потому что президент будет все же Nixon, но тот же Гугл возможность неправильного написания учитывает

Более того, Nixon вполне может означать Nixon Watches, а вот Richard Nixon — с большой долей верятности указывает на президента

>>>>Что делть с национальными правилами предоставления информации?

PD>>>Сайт обычно делается либо на одном языке, либо отдельные части для разных языков.

M>>Нет, отдельные части в виде собственно отдельных частей не делаются.

PD>Собственно или не собственно, но страниц на двух языках одновременно я не видел.

Аааа, в этом смысле...

PD>>>Структура одна. Граф с выделенным узлом (home page)

M>>Зато граф очень разный

Причем точек входа может быть несколько, и каждая из этих точек может быть равнозначной

PD>Это не принципиально. В крайнем случае я готов на несколько несвязных графов с выделенной вершиной у каждого.

В случае last.fm — это (потенциально) бесконечное количество таких графов потому что, повторюсь, граф

Bjork -> Mamut -> Glory Box -> Jaropolk

абсолютно равноначен графу

Jaropolk -> Glory Box -> Mamut -> Bjork

При этом граф

Mamut -> Jaropolk

также абсолютно равнозначен. Или графы

       Jazz - Jan Garbarek
     /
Bjork - Electronic - Miles Davies
     \ 
       Classical - Wolfgang Amadeus Mozart

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

Их здесь бесконечное количество

M>>Какого из графов? Как узнать, что

M>>- Павел — Дворкин — отель
M>>важнее, чем
M>>- отель — Павел — Дворкин

PD>Никак. Я еще раз говорю — это вручную наполнители сайта должны решить. Если сайт по отелям, то важнее отель, потому что мои ФИО — это отзыв об отеле. А вот если я — владелец сети отелей

— то важнее ФИО.

А если сайт — last.fm?
А если сайт — блог?

M>>Что делать с циклическими ссылками? Или равнозначными путями?

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

Потому что это в общем случае просто невозможно

M>>Хочу дешевый отель в турции, в анталии, с описанием. Под "описание" попадет и вот это и вот это и вообще чье-то описание в стиле "были на море". Как тот же ЖЖ сможет выдать на это иерархическую структуру? Как ЖЖ вообще сможет выавать хоть какую-то иерархическую структуру?

M>>А с гуглем уже сейчас можно попытаться это найти

PD>А я вообще-то Гугл не предлагаю закрыть

Хорошо, как тогда создать граф для, например, вот этого текста. Вот пришел uberGoogle и Универсальным Языком Запросов молвил нечеловечиским голосом: "а дай ка, uberLJ, граф по своим страницам, да так, чтобы понял я, что такая-то и такая-то страница релевантны для поиска 'отдых в Анталии', а такая-то и такая-то нерелевантны"

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

Да это всё очередной утопический проект по Созданию Классификатора Для Всего. Отличный стеб на эту тему можно найти в Quicksilver Стивенсона:

Если будем держаться подальше от политики, то уже через несколько поколений сможем запускать крылатые колесницы на Луну. Надо устранить лишь некоторые преграды на пути прогресса.
– Какие же именно?
– Латынь.
– Латынь?! Но она…
– Да, она универсальный язык учёных, богословов и прочих. А как звучна! Скажешь на ней любую галиматью, и ваш брат университетский выученик придёт в восторг или по крайней мере сконфузится. Вот так Папам и удавалось столько веков впаривать людям дурную религию – они просто говорили на латыни. Зато если перевести их замысловатые фразы на философский язык, сразу проявятся противоречия и размытость.
– М м м… я бы сказал даже, что на правильном философском языке, когда бы такой существовал, нельзя было бы, не преступая законов грамматики, выразить ложное утверждение.
– Вы только что сформулировали самое краткое из его определений, – весело произнёс Уилкинс. – Уж не вздумалось ли вам со мною соперничать?
– Нет, – торопливо отвечал Даниель, со страху не различивший юмора. – Я лишь рассуждал по аналогии с декартовым анализом, в котором, при чёткой терминологии, любое ложное высказывание будет неправомерным.
– При чёткой терминологии! Вот она, загвоздка! – сказал Уилкинс. – Чтобы записать термины, я сочиняю философский язык и всеобщий алфавит – на котором образованные люди всех рас и народов будут выражать свои мысли.
– Я к вашим услугам, сэр, – промолвил Даниель. – Когда можно приступать?
– Прямо сейчас! Пока Гук не покончил с лягушками – если он придёт и застанет вас без дела, то закабалит , как чёрного невольника. Будете разгребать требуху или, что хуже, проверять его часы, стоя перед маятником и считая… колебания… с утра… до самого… вечера.
Подошёл Гук, не только горбатый, но и кособокий, длинные каштановые волосы висели нечёсаными прядями. Он немного выпрямился и задрал голову, так что волосы разошлись, словно занавес, явив бледный лик. Щетина подчеркивала худобу запавших щёк, отчего серые глаза казались ещё больше.
Гук сказал:
– Лягушки тоже.
– Меня уже ничто не удивляет, мистер Гук.
– Я заключаю, что из них состоят все живые существа.
– А вас не посещает мысль что нибудь из этого записать? Мистер Гук? Мистер Гук?
Однако Гук уже ушёл на конюшню, ставить какой то новый эксперимент.
– Из чего состоят??? – спросил Даниель.
– В последнее время, всякий раз, глядя на что либо через свой микроскоп, мистер Гук обнаруживает, что оно сложено из крохотных ячеек, как стена – из кирпичей, – сообщил Уилкинс.
– И на что же походят эти кирпичи?
– Он не зовет их кирпичами. Не забывайте, они полые. Он решил назвать их клетками… Впрочем, в эту чепуху вам встревать незачем. Идёмте со мной, любезный Даниель. Выбросьте клетки из головы. Чтобы постичь философский язык, вы должны усвоить, что всё на Земле и на Небе можно разделить на сорок различных родов… в каждом из которых, разумеется, есть свои более мелкие категории.
Уилкинс провел его в помещение для слуг, где стояла конторка, а книги и бумаги громоздились бессистемно, словно пчелиные соты. Уилкинс двигался так стремительно, что от поднятого им ветра по комнате запорхали листки. Даниель поймал один и прочёл:
– «Петушье просо, листовник сколопендровый, кандык, гроздовик, взморник, кукушкины слёзы, заразиха, петров крест, ложечница лекарственная, цикламен, камнеломка, заячья капуста, подмаренник, плаун вонючий, цикорий, осот, одуванчик, пастушья сумка, икотник, вербейник, вика».
Уилкинс нетерпеливо кивал.
– Коробочкообразующие травы, не колокольчатые, и ягодоносные вечнозелёные кустарники. Каким то образом они затесались среди желуденосных и орехоносных деревьев.
– Так философский язык – своего рода ботанический…
– Гляньте на меня – я содрогаюсь! Содрогаюсь от одной мысли. Даниель, умоляю вас, сосредоточьтесь и вникните. В этом списке у нас все животные от глиста до тигра. Здесь – классификация хворей: от гнойников, чирьев, нарывов, жировиков и коросты до ипохондрической болезни, заворота кишок и удушья.
– Удушье – хворь?
– Превосходный вопрос. За дело – и разрешите его! – прогремел Уилкинс.
Даниель тем временем поднял с пола ещё листок.
– «Палка, женило, ствол…»
– Синонимы слов «срамной уд», – нетерпеливо произнёс Уилкинс.
– «Побирушка, голоштанник, христарадник…»
– Синонимы к слову «нищий». В философском языке будет лишь одно слово для срамных удов, одно слово для нищих. Быстро: Даниель, есть ли разница между тем, чтобы стонать и сетовать?
– Я бы сказал, да, но…
– С другой стороны, можно ли объединить под общим названием коленопреклонение и реверанс?
– Я… я не знаю, доктор!
– Тогда, как я говорю, за работу! Сам же я сейчас увяз в бесконечном отступлении по поводу ковчега.
– Который Завета? Или…
– Другой.
– А он здесь при чём?
– Очевидно, в философском языке должно быть по одному и только одному слову для каждого типа животных. Каждое обязано отражать классификацию; как названия жерди и бруса должны быть заметно схожи, так и наименования малиновки и дрозда. При этом птичьи термины не должны походить на рыбьи.
– Замысел представляется мне… э… дерзким.
– Пол Оксфорда шлёт мне нудные перечни. Мое – наше – дело их упорядочить, составить таблицу всех птиц и зверей в мире. В таблицу уже занесены животные, которые досаждают другим животным: блоха, вошь. Предназначенные к дальнейшим метаморфозам: гусеница, личинка. Однорогие панцирные крылатые насекомые. Скорлупчатые конусообразные бескровные твари, и (предвосхищая ваш вопрос) я разделил их на спиральнозавитых и всех прочих. Чешуйчатые речные рыбы, травоядные длиннокрылые птицы, плотоядные котообразные звери – так или иначе, когда я составил все перечни и таблицы, мне стало ясно (возвращаясь к «Книге Бытия», глава шестая, стихи пятнадцатый – двадцать второй), что Ной каким то образом затолкал этих тварей в посудину из дерева гофер длиной триста локтей! Я испугался, что некоторые континентальные учёные, склонные к афеизму , способны злоупотребить моими словами и обратить их в доказательство того, что события, описанные в Книге Бытия, якобы не могли произойти.
– Рискну даже предположить, что некие иезуиты направят их против вас – как свидетельство ваших будто бы афеистических воззрений, доктор Уилкинс.
– Истинная правда, Даниель! Посему совершенно необходимо приложить, отдельной главою, полный план Ноева Ковчега и показать не только, где размещалось каждое животное, но и где хранился фураж для травоядных, где стоял скот для хищников и где хранился фураж, которым кормили жвачных, пока их не съедят хищники.
– Еще нужна была пресная вода, – задумчиво произнёс Даниель.
Уилкинс, который имел обыкновение, говоря, наступать на собеседника, покуда тот не начинал пятиться, схватил кипу бумаг и огрел Даниеля по голове.
– Читайте Библию, неуч! Дождь шёл без остановки!
– Конечно, конечно, они могли пить дождевую воду, – проговорил совершенно раздавленный Даниель.
– Мне пришлось несколько вольно обойтись с мерой «локоть», – заговорщицки поведал Уилкинс, – но я думаю, Ною должно было хватить восьмисот двадцати пяти овец. Я имею в виду, чтобы кормить хищников.
– Овцы занимали целую палубу?!
– Дело не в пространстве, которое они занимали, а в навозе, который надо было выгребать за борт – представьте, какая это работа!… Так или иначе, вы понимаете, что история с Ковчегом надолго застопорила создание философского языка. А вас я попрошу перейти к оскорбительным выражениям.
– Сэр!
– Не задевает ли вас, Даниель, когда ваш брат лондонец бросается такими словами, как «гнусный подлец», «жалкое ничтожество», «хитрый пройдоха», «праздный бездельник» или «льстивый угодник»?
– Смотря кто кого так обозвал…
– Попробую проще: «развратная шлюха».
– Это тавтология и потому оскорбляет просвещённый слух.
– «Безмозглый фат».
– Тоже тавтология, как «льстивый угодник» и всё прочее.
– Итак, очевидно, что в философском языке не потребуются отдельные имена прилагательные и существительные для подобных понятий.
– Как вам «грязный неряха»?
– Превосходно! Запишите это, Даниель!
– «Беспутный повеса», «язвительный зубоскал», «вероломный предатель»… – Покуда Даниель продолжал в том же духе, Уилкинс подскочил к конторке, вынул из чернильницы перо, стряхнул избыток чернил и, вложив перо в руку Даниеля, подвёл того к чистому листу.
Итак, за работу. В несколько коротких часов Даниель исчерпал оскорбительные выражения и перешёл к добродетелям (умственным, естественным и христианским), цветам, звукам, вкусам и запахам, занятиям (например, плотничеству, шитью, алхимии) и так далее. Дни проходили за днями. Уилкинсу надоедало, когда Даниель (или кто то ещё) слишком много работает, поэтому они часто устраивали «семинары» и «симпозиумы» на кухне – варили флип из мёда, которым учёных исправно снабжал готический апиарий Рена. Чарльз Комсток, пятнадцатилетний сын их высокородного хозяина, заходил послушать Уилкинса и Гука. Как правило, он приносил с собой письма Королевскому обществу от Гюйгенса, Левенгука, Сваммердама, Спинозы. Нередко в письмах содержались новые понятия, и Даниелю приходилось втискивать их в таблицы философского языка.
Даниель прилежно составлял перечень предметов, которыми человек может владеть (акведуки, дворцы, тележные оси, дверные петли и так далее), когда Уилкинс срочно позвал его вниз. Юноша спустился на первый этаж и увидел, что преподобный держит в руках внушительного вида письмо, а Чарльз Комсток расчищает стол: скатывает в рулоны чертежи Ковчега и расписания кормлений для восьмисот двадцати пяти овец, освобождая место для более важных занятий. Карл II, милостью Божьей король Англии, прислал им письмо.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>>>Это справедливо только для русского языка

PD>>Не думаю. Сказав Nickson, мы тем самым уже установили ассоциацию (в уме) с президентом США. Сказав "Richard" — мы не установили.
M>В случае last.fm — это (потенциально) бесконечное количество таких графов потому что, повторюсь, граф
M>

M>Bjork -> Mamut -> Glory Box -> Jaropolk

M>абсолютно равноначен графу
M>[q]
M>Jaropolk -> Glory Box -> Mamut -> Bjork

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

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

M>Абсолютно равнозначны между собой. Причем Bjork я вообще наугад выбрал. Я мог выбрать "вершиной" абсолютно любой из "узлов" сайта — тэг, пользователя, жанр, исполнителя, произведение, радиостанцию.

Еще раз — структура сайта, его остовное дерево (от home page и далее) определяет форму графа. Если не хочешь остовное дерево, а хочешь граф целиком — бери как есть все ссылки, но это просто будет сложнее. Придется граф строить целиком. Но он, вообще говоря, для сайта один (мб несвязный).

>О каких графах мы говорим?

Их здесь бесконечное количество

Граф один для сайта. Путей много в нем.

M>А если сайт — last.fm?

Честно говоря, не знаю, что это такое.

M>А если сайт — блог?

И что ? Там нет иерархии никакой ? По авторам хоть есть ?

M>Потому что это в общем случае просто невозможно

Я не думаю, что обход дерева (графа) невозможен.

M>Хорошо, как тогда создать граф для, например, вот этого текста. Вот пришел uberGoogle и Универсальным Языком Запросов молвил нечеловечиским голосом: "а дай ка, uberLJ, граф по своим страницам, да так, чтобы понял я, что такая-то и такая-то страница релевантны для поиска 'отдых в Анталии', а такая-то и такая-то нерелевантны"

Еще раз — граф строится для сайта, а не для страниц. Если для этой страницы будет ключевое слово "Анталия", если для родителя будет ключевое слово "отдых" (или у этой будет отдых Анталия — 2 слова), то и найдется.

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

PD>Дело не в равнозначности графов. Теоретически они все равнозначны. А практически всегда есть более важное, и менее важное. Точно так же, как в организации теоретически есть тоже граф сотрудников, а практически есть корень в виде президента и далее по иерархии.

Хорошо. У нас будет граф:

                 last.fm____________________________________________________
                       /       |                 \               \          \
         ________users       artists             songs           tags       genres
         |     |              |    \              |              /   \       |    \
       Mamut Jaropolk      Bjork Portishead     "Glory Box"    best worst   jazz electronica

И между каждым из узлов будут связи с (потенциально) каждым из других узлов. Как это нам поможет?

M>>Абсолютно равнозначны между собой. Причем Bjork я вообще наугад выбрал. Я мог выбрать "вершиной" абсолютно любой из "узлов" сайта — тэг, пользователя, жанр, исполнителя, произведение, радиостанцию.

PD>Еще раз — структура сайта, его остовное дерево (от home page и далее) определяет форму графа. Если не хочешь остовное дерево, а хочешь граф целиком — бери как есть все ссылки, но это просто будет сложнее. Придется граф строить целиком. Но он, вообще говоря, для сайта один (мб несвязный).

И как он нам поможет?

M>>А если сайт — last.fm?
PD>Честно говоря, не знаю, что это такое.

Советую посмотреть

M>>А если сайт — блог?
PD>И что ? Там нет иерархии никакой ? По авторам хоть есть ?

И как иерархия по авторам позволит нам найти описание отеля в Анталии?

M>>Потому что это в общем случае просто невозможно
PD>Я не думаю, что обход дерева (графа) невозможен.

21 миллион пользователей (потенциально — между каждым из них есть связь)
предположим, что исполнителей на порядок меньше и песен тоже, ну и тэгов. Сотня жанров
Между каждым из этих узлов (потенциально) есть связь. Причем связи часто меняются.

Сколько ресурсов надо будет потратить на генерацию такого графа?

M>>Хорошо, как тогда создать граф для, например, вот этого текста. Вот пришел uberGoogle и Универсальным Языком Запросов молвил нечеловечиским голосом: "а дай ка, uberLJ, граф по своим страницам, да так, чтобы понял я, что такая-то и такая-то страница релевантны для поиска 'отдых в Анталии', а такая-то и такая-то нерелевантны"

PD>Еще раз — граф строится для сайта, а не для страниц. Если для этой страницы будет ключевое слово "Анталия", если для родителя будет ключевое слово "отдых" (или у этой будет отдых Анталия — 2 слова), то и найдется.

Откуда у этих страниц найдутся такие ключевые слова и такие родители?

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

PD>>Дело не в равнозначности графов. Теоретически они все равнозначны. А практически всегда есть более важное, и менее важное. Точно так же, как в организации теоретически есть тоже граф сотрудников, а практически есть корень в виде президента и далее по иерархии.

M>Хорошо. У нас будет граф:
M>

M>                 last.fm____________________________________________________
M>                       /       |                 \               \          \
M>         ________users       artists             songs           tags       genres
M>         |     |              |    \              |              /   \       |    \
M>       Mamut Jaropolk      Bjork Portishead     "Glory Box"    best worst   jazz electronica

M>

M>И между каждым из узлов будут связи с (потенциально) каждым из других узлов. Как это нам поможет?

Как нам это поможет для данного случая — не знаю, давай другой пример рассмотрим

www.samsung.ru. Компания довольно приличная по размерам, на ее примере и разберем. Почему на ее примере — просто я недавно купил их микроволновую печь

Идем на Home page (A) Там, увы, flash, ну да ладно.

Продукты Бизнес Поддержка ...

Если подсветить "Продукты " — появляется "Телевизоры" "Аудио" "Видео"...
Если подсветить "Бизнес " — появляется "Системы связи" "Полупроводники" ...

И другие аналогично

Пойдем в "Продукты" (B)

Там Телевизоры
Жидкокристаллические
Плазменные
SlimFit

Бытовая техника
Холодильники
Стиральные машины
Микроволновые печи (C)
...

Пойдем в Микроволновые печи
Соло
Гриль
Супергриль
Конвекция

Пойдем в Гриль (D)
Там модели

Ну все, хватит. Естественно, на других путях будет аналогичное

Итак, страница A, т.е home page. Помещаем туда ключевые слова

продукты товары ... (в общем, все синонимы для продукты)
бизнес промышленность решения ... (все синонимы для бизнес)

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

Страница B

Телевизоры телики теле "ящики для идиотов"

аудио плееры музцентры "музыкальные центры" хрюкалки
"бытовая техника" быт "домашняя техника"

Страница C

"микроволновая печь" "микроволновка" "духовка"

Страница D

Гриль Спираль

Ну и т.д.

Теперь запрос

Продукты — быт — духовка

ведет нас прямым образом на

http://www.samsung.ru/products/home/microwave/

а запрос

Продукты — быт — духовка — спираль

на

http://www.samsung.ru/products/home/microwave/grille/

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

Продукты — дача — духовка

ввиду отсутствия "дача" приведет к сообщению следующего рода

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

(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть. Оказалось успешно. Вот если бы запрос был

Продукты — дача — культиватор

то был бы просто отказ — ну нет у нас культиваторов)

Ну и т.д. Другие варианты сам можешь продумать.

Что здесь нереального ?

Кстати. Не помню где я читал, и не поручусь за точность этого высказывания, но якобы средний человек имеет лексикон всего в 2000 слов (разумеется, знает он больше, но употребляет обычно не более 2000). И какой процент от них имеет смысл в применении к этому сайту ? Сомневаюсь, что более 500-1000 на все страницы, скорее меньше.

О "горизонтальных" ссылках. Конечно, они есть. Но сейчас их можно либо

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

, то от этой печи будет "важная связь" на мобильник. И тогда поиск

Продукты — дача — духовка — мобила

приведет вас на эту печь, и в ответе будет информация о встроенном мобильнике

А теперь пару слов о LJ и FM.

Напомню, с чего вся эта дискуссия началась. Речь шла о получении чего-то от сайта, размеров, веса и цены. Цены тут точно нет, вместо размера для микровольновки возьмем объем, веса, увы, нет. Так что только объем. Ладно

Если сейчас попытаться получить объем,, то остается только найти не знаю каким способом страницу, например

http://www.samsung.ru/products/home/microwave/grille/ce287mnr/

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

Если же реализовать то, о чем я говорю, то этот запрос будет выглядеть вполне осмысленно.

Что касется LJ — да, скорее всего там это работать не будет. Во-первых, там иерархия верхнего уровня сделана не на страницах, а на именах сайтов, что за пределами моих рассуждений. Во-вторых, иерархической структуры там нет — блог он и есть блог.

Насчет last.fm — затрудняюсь сказать. Иерархическая структура там просматривается, но удастся ли что-то сделать — сказать не берусь.

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

Если кто-то с последним утверждением не согласен — OK, предлагаю построить такой запрос

Дайте объем микроволновой печи ce287mnr.

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

PD>Напомню, с чего вся эта дискуссия началась. Речь шла о получении чего-то от сайта, размеров, веса и цены. Цены тут точно нет, вместо размера для микровольновки возьмем объем, веса, увы, нет. Так что только объем. Ладно

PD>Если сейчас попытаться получить объем,, то остается только найти не знаю каким способом страницу, например

PD>http://www.samsung.ru/products/home/microwave/grille/ce287mnr/

PD>и парсить ее в надежде, что после слова "Объем" и тире за ним стоит именно объем.

Откуда этот вывод? Кто парсит ссылку? Откуда возникла необходимость парсить ссылку?

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

Если же реализовать то, о чем я говорю, то этот запрос будет выглядеть вполне осмысленно.

Не будет. Ниже.

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

Еще раз советую внимательно посмотреть на такую вещь, как API, которая уже давно существует.

Например:
EBay API
Amazon API
Google APIs

Предположения об Универсальном Языке Запросов строятся на неправильных предпосылках:

1. Что граф запросов возможно составить для произвольных данных для любого сайта

Обработка любого запроса — это нетривиальная задача. ПОтому что этот самый Универсальный Язык Запросов кто-то где-то должен обработать. А там, по ту сторону баррикад, у него окажется поисковое пространство порядка 5000 x 5000 x 10000 и все, приплыли.

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

2. Что любой сайт с легкостью сможет построить и предоставить граф для произвольного запроса для своих данных

Есть сайты, для которых графы создать невозможно (блоги) или слишком сложно, чтобы этим кто-то занимался (last.fm)

3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI

Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:

<request>
    <primaryRequest>
        elephant
    </primaryRequest>
    <secondaryRequest>
        <prioritizeKey>
            <color>pink</color>
        </prioritizeKey>
    </secondaryReqest>
</request>

и если сайт понимает такой вопрос, то он выведет доступных слонов, отдавая предпочтение розовым. Что, вобщем, ничем не отличается от Универсального Языка Запросов.

Потому что УЯЗ упирается ровно в одно: предастление данныз на сайте. Одно — в виде сайта, а одно — в виде графа. Большинство веб-программистов не знают, что такое MVC, а тут еще графы какие-то

PD>Если кто-то с последним утверждением не согласен — OK, предлагаю построить такой запрос

PD>Дайте объем микроволновой печи ce287mnr.

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

То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

PD>>и парсить ее в надежде, что после слова "Объем" и тире за ним стоит именно объем.

M>Откуда этот вывод? Кто парсит ссылку? Откуда возникла необходимость парсить ссылку?

Парсить не ссылку, конечно, а HTML, полученный по ссылке. Делать так предложил Синклер, к нему и все вопросы.

http://www.rsdn.ru/forum/message/2901089.1.aspx

M>Еще раз советую внимательно посмотреть на такую вещь, как API, которая уже давно существует.

M>Например:
M>EBay API
M>Amazon API
M>Google APIs

Посмотрю, когда будет время.

M>Предположения об Универсальном Языке Запросов строятся на неправильных предпосылках:

M>1. Что граф запросов возможно составить для произвольных данных для любого сайта

Либо ты меня не хочешь понять, либо мы о разном говорим. Я тебе пример с samsung привел. Нет там произвольных данных. Какие именно данные я предложил внести — я указал конкретно. Там сотни 2-3 слов будет, ну пусть 5

M>Обработка любого запроса — это нетривиальная задача. ПОтому что этот самый Универсальный Язык Запросов кто-то где-то должен обработать. А там, по ту сторону баррикад, у него окажется поисковое пространство порядка 5000 x 5000 x 10000 и все, приплыли.

Чего ? Это с какой стати-то ? Там сидит дерево, которое я описал, в деталях. Высота этого дерева 5-6. Ширина 6-8. В каждом узле пусть будет 30-50 синонимов. Что за проблема пройти один путь в этом дереве, какие тут миллиарды. ?

Вот возьми и нарисуй то дерево, что я привел. И сразу все поймешь.

M>В итоге любой неправильный запрос бдет программистом сайта просто отсекаться и никаких "вот для дачи у нас нет, посмотрите вот такие" не будет.

Хорошо. Я привел примеры того, что будет давать результат. Приведи пример запроса, на который ответа не будет. Просьба остаться в пределах микроволновых печей, так как времени изучать весь сайт у меня нет.

M>2. Что любой сайт с легкостью сможет построить и предоставить граф для произвольного запроса для своих данных

А чего тут строить-то ? Я же сказал — это ключевые слова. А запрос идет по внутренней логической структуре сайта. Она тут вполне очевидна и я ее описал.

M>Есть сайты, для которых графы создать невозможно (блоги) или слишком сложно, чтобы этим кто-то занимался (last.fm)

Есть! Я не панацею предложил, уже сказал. Но по совести — что ты там за запросы к блогу устраивать собираешься ?

M>3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI
M>Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:
M>

M><request>
M>    <primaryRequest>
M>        elephant
M>    </primaryRequest>
M>    <secondaryRequest>
M>        <prioritizeKey>
M>            <color>pink</color>
M>        </prioritizeKey>
M>    </secondaryReqest>
M></request>
M>

Ну и прекрасно. Только объясни, как такой запрос из броузера послать. Как с помощью какого-нибудь WebClient — я понимаю, а вот как с помощью броузера — нет.

Дано — запущен IE, в нем about:blank
Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
Решение ?

M>и если сайт понимает такой вопрос, то он выведет доступных слонов, отдавая предпочтение розовым. Что, вобщем, ничем не отличается от Универсального Языка Запросов.

Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !

M>Потому что УЯЗ упирается ровно в одно: предастление данныз на сайте. Одно — в виде сайта, а одно — в виде графа. Большинство веб-программистов не знают, что такое MVC, а тут еще графы какие-то

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

M>То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ

Если бы то, о чем я писал, было реализовано, это было бы легко возможно.

M>>Откуда этот вывод? Кто парсит ссылку? Откуда возникла необходимость парсить ссылку?

PD>Парсить не ссылку, конечно, а HTML, полученный по ссылке. Делать так предложил Синклер, к нему и все вопросы.

PD>http://www.rsdn.ru/forum/message/2901089.1.aspx

Много раз было сказано, что это — крайний случай.

M>>Предположения об Универсальном Языке Запросов строятся на неправильных предпосылках:

M>>1. Что граф запросов возможно составить для произвольных данных для любого сайта

PD>Либо ты меня не хочешь понять, либо мы о разном говорим. Я тебе пример с samsung привел. Нет там произвольных данных. Какие именно данные я предложил внести — я указал конкретно. Там сотни 2-3 слов будет, ну пусть 5

Я же привел контрпример — блоги и last.fm. В одном случае дерева просто не будет, во втором постройка дерева — слишком накладно.

M>>Обработка любого запроса — это нетривиальная задача. ПОтому что этот самый Универсальный Язык Запросов кто-то где-то должен обработать. А там, по ту сторону баррикад, у него окажется поисковое пространство порядка 5000 x 5000 x 10000 и все, приплыли.

PD>Чего ? Это с какой стати-то ? Там сидит дерево, которое я описал, в деталях. Высота этого дерева 5-6. Ширина 6-8. В каждом узле пусть будет 30-50 синонимов. Что за проблема пройти один путь в этом дереве, какие тут миллиарды. ?

PD>Вот возьми и нарисуй то дерево, что я привел. И сразу все поймешь.

Какое дерево?

Если вы хотите слетать из BOS в LAX и обратно через две недели с возвратом через три, так, чтобы было окно в 24 часа перед вылетом в обе стороны, то ограничение возможных полетов (максимум 3 вылета в течение 10 часов) состоит в выборке из примерно 5000 вариантов полета туда и 5000 вариантов полета оттуда. Список этих полетов достигается простым поиском по графу, которые кто угодно может сделать в долб секунды.

Сама проблема состоит в том, что один фиксированный план полета с только двумя вылетами туда/обратно может содерждать более 10 000 комбинаций стоимости, каждая из которых содержит строгие ограничения, которые должны быть сопоставлены с другими стоимостями и полетами. Таким образом область поиска на одно путешествие — 5000 x 5000 x 10000, и наивной программе придется совершать множество вычислений для тго, чтобы проверить все возможности

Все ключевое — во втором абзаце. orbitz.com, о котором идет речь просто не даст никому гулять ни по какому графу.

M>>В итоге любой неправильный запрос бдет программистом сайта просто отсекаться и никаких "вот для дачи у нас нет, посмотрите вот такие" не будет.

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

Цитирую:

Продукты — дача — духовка

ввиду отсутствия "дача" приведет к сообщению следующего рода

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

(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть)

В реальном мире все остановится на слове дача.

M>>2. Что любой сайт с легкостью сможет построить и предоставить граф для произвольного запроса для своих данных

PD>А чего тут строить-то ? Я же сказал — это ключевые слова. А запрос идет по внутренней логической структуре сайта. Она тут вполне очевидна и я ее описал.

Нет такого понятия, как "внутренняя логическая структура". Она есть только для сайтов, которые можно уложить в рамки какого-то каталога (оно же дерево оно же граф). Пусть таких сайтов и большинство

M>>Есть сайты, для которых графы создать невозможно (блоги) или слишком сложно, чтобы этим кто-то занимался (last.fm)

PD>Есть! Я не панацею предложил, уже сказал. Но по совести — что ты там за запросы к блогу устраивать собираешься ?

Описание отдыха в Анталии. А что, с точки зрения УЯЗ все хорошо: лето — отдых — анталия. А низзя. Потому-что графа нет. И не может быть

M>>3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI
M>>Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:
M>>

M>><request>
M>>    <primaryRequest>
M>>        elephant
M>>    </primaryRequest>
M>>    <secondaryRequest>
M>>        <prioritizeKey>
M>>            <color>pink</color>
M>>        </prioritizeKey>
M>>    </secondaryReqest>
M>></request>
M>>

PD>Ну и прекрасно. Только объясни, как такой запрос из броузера послать. Как с помощью какого-нибудь WebClient — я понимаю, а вот как с помощью броузера — нет.

PD>Дано — запущен IE, в нем about:blank
PD>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>Решение ?

Заходим на http://orbitz.com/ и внимательно вдумываемся в то, что происходит при нажатии кнопки Submit.

Некий uberClient так же не сможет с нуля создать какой-либо запрос к чему-либо.

M>>и если сайт понимает такой вопрос, то он выведет доступных слонов, отдавая предпочтение розовым. Что, вобщем, ничем не отличается от Универсального Языка Запросов.

PD>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !

Зачем? Невозможно создать язык, подходящий для всех случаев.

M>>Потому что УЯЗ упирается ровно в одно: предастление данныз на сайте. Одно — в виде сайта, а одно — в виде графа. Большинство веб-программистов не знают, что такое MVC, а тут еще графы какие-то

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

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

Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать

M>>То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ

PD>Если бы то, о чем я писал, было реализовано, это было бы легко возможно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Парсить не ссылку, конечно, а HTML, полученный по ссылке. Делать так предложил Синклер, к нему и все вопросы.
Павел, я еще раз напоминаю, что это — от безысходности. Если автор веб-приложения не удосужился сделать к нему веб-сервис, то всё, привет, приплыли.
Задача в сделанной тобой постановке неразрешима.
И это никак не связано с вебностью приложений.
Ну вот ты видел когда-нибудь десктопные аналоги сайта самсунга? Сходи в ближайший магазин типа Планета Электрика, возьми компакт-диск с каталогом светильников. И попробуй представить себе приложение, которое вынимает из него, скажем, мощность светильника такой-то модели. Точно так же ты ничего не сможешь сделать, потому что этот каталог скорее всего представляет собой тупо набор картинок, на которых все ТТХ нарисованы. И даже такой тупой и ненадежный анализ, как регексп по html, тебе там будет вовсе недоступен. И точно так же, как и для сайта самсунга, нет никаких шансов, что приложение написанное для каталога 2007 года продолжит работать с каталогом 2008го.

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

PD>Посмотрю, когда будет время.
Ок, давай сменим постановку вопроса. Предположим, что мы с тобой и Мамутом как раз представляем компанию Самсунг, и мы хотим предоставить программный доступ к каталогу товаров нашей компании. Тебя это интересует? Как должен выглядеть API самсунга? Ну так я вроде давал ссылку на книжку про RESTful Web Services.
Там всё написано очень подробно.

M>>3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI
M>>Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:
M>>

M>><request>
M>>    <primaryRequest>
M>>        elephant
M>>    </primaryRequest>
M>>    <secondaryRequest>
M>>        <prioritizeKey>
M>>            <color>pink</color>
M>>        </prioritizeKey>
M>>    </secondaryReqest>
M>></request>
M>>

PD>Ну и прекрасно. Только объясни, как такой запрос из броузера послать. Как с помощью какого-нибудь WebClient — я понимаю, а вот как с помощью броузера — нет.
Павел, никакой нужды посылать такие запросы из браузера нету. Браузером пользуется человек. Неужели ты не смог найти на сайте самсунга объем выбранной микроволновки? Значит для человека всё уже сделано. Ну, не всё, если почитать книжки Якоба Нильсена, то видно, что хороших сайтов по-прежнему мало. Но все необходимые принципы уже давно сформулированы, все необходимые технические средства есть, остается только применить их на практике.

PD>Дано — запущен IE, в нем about:blank
PD>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>Решение ?
Павел, прекрати заниматься херней. Нет вот этого "надо". Есть две разные задачи:
1. Найти объем микроволновки такой-то модели. Прекрасно решается существующими веб приложениями. Смотреть также: google.com, yandex.ru.

PD>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !
Павел, а вот тут начинается невозможная утопия. Потому, что для самсунга запросы будут одни, а для орбитза — совсем другие. Неужели так трудно понять, что невозможно придумать один язык запросов, который бы подходил и тем и тем?
Еше раз поясняю: для конкретной задачи придется изобретать свой конкретный язык запросов. Есть определенные соображения о том, как этот язык должен быть реализован. В частности, делать один endpoint, в который пихается разнообразный XML, и который возвращает произвольный XML — плохая идея. Математически это, конечно, полностью эквивалентно любому другому API, но с точки зрения практики есть масса соображений, по которым RPC-style сосет, а Resource-oriented style рулит.

M>>То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ
PD>Если бы то, о чем я писал, было реализовано, это было бы легко возможно.
Рекомендую посмотреть на то, что уже есть. Ссылки на API тебе давали. Самсунг — не очень хороший пример. Посмотри Амазон.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

PD>>Вот возьми и нарисуй то дерево, что я привел. И сразу все поймешь.

M>Какое дерево?

Дерево сайта samsung.

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

M>Цитирую:
M>

M>Продукты — дача — духовка

M>ввиду отсутствия "дача" приведет к сообщению следующего рода

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

M>(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть)

M>В реальном мире все остановится на слове дача.

Я не знаю, что понимается под реальным миром, но если в программе поиск в одном из узлов на уровне N заканчивается неудачей, а у нас есть еще данные на уровне N+1, то никто не мешает проверить, нельзя ли найти это слово с уровня N+1, если пройти по все вариантам уровня N

Уровень N — бытовая быт домашняя
Уровень N+1 духовка

Ищем на уровне N "дача", N+1 — духовка. Нет дачи на уровне N. Ищем духовку на уровне N+1. Есть она там. Значит, духовка есть, но не для дачи.

M>Нет такого понятия, как "внутренняя логическая структура". Она есть только для сайтов, которые можно уложить в рамки какого-то каталога (оно же дерево оно же граф). Пусть таких сайтов и большинство

Ну и прекрасно. Пусть для большинства это и получится.

M>Описание отдыха в Анталии. А что, с точки зрения УЯЗ все хорошо: лето — отдых — анталия. А низзя. Потому-что графа нет. И не может быть

От лето — скорее всего нет. А вот от страны — есть. Могу попробовать на примере какого-нибудь сайта туроператора прокрутить. Не сегодня.

PD>>Дано — запущен IE, в нем about:blank
PD>>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>>Решение ?

M>Заходим на http://orbitz.com/ и внимательно вдумываемся в то, что происходит при нажатии кнопки Submit.

Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.

M>Некий uberClient так же не сможет с нуля создать какой-либо запрос к чему-либо.

А вот это неясно почему. Что, так нельзя ?

client.Method = "POST";
client.Text = XMLText;
client.URL = "a.com";
client.Send();

PD>>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !

M>Зачем? Невозможно создать язык, подходящий для всех случаев.

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

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

Ну тогда поясни, что такое может измениться на samsung.ru, чтобы мы приплыли.

M>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать

Еще бы!

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

Вообще-то я решил тебе не отвечать, но сделаю здесь исключение.

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

Ну тогда приплыли вообще. Можно поинтересоваться насчет web-сервисов www.samsung.com, www.microsoft.com, www.ibm.com и далее, реализующих эту функциональность ? То. что какие-то другие сервисы там могут быть — к делу не относится.

Так что если из этого исходить — приплыли, да

S>Задача в сделанной тобой постановке неразрешима.

Доказательство. Так сказал Синклер, и выделил это жирным шрифтом.

S>Ну вот ты видел когда-нибудь десктопные аналоги сайта самсунга? Сходи в ближайший магазин типа Планета Электрика, возьми компакт-диск с каталогом светильников. И попробуй представить себе приложение, которое вынимает из него, скажем, мощность светильника такой-то модели. Точно так же ты ничего не сможешь сделать, потому что этот каталог скорее всего представляет собой тупо набор картинок, на которых все ТТХ нарисованы. И даже такой тупой и ненадежный анализ, как регексп по html, тебе там будет вовсе недоступен. И точно так же, как и для сайта самсунга, нет никаких шансов, что приложение написанное для каталога 2007 года продолжит работать с каталогом 2008го.

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

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

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

Все остальное поскипано. По одной простой причине. Мамут со мной не согласен, но он пытается меня понять. А ты просто знаешь истину в последней инстанции и вещаешь ее. А понять не хочешь. Чего хотя бы это стоит

S>Павел, а вот тут начинается невозможная утопия. Потому, что для самсунга запросы будут одни, а для орбитза — совсем другие. Неужели так трудно понять, что невозможно придумать один язык запросов, который бы подходил и тем и тем?
Еше раз поясняю: для конкретной задачи придется изобретать свой конкретный язык запросов.

Ты хоть об одном бы подумал. Ведь то, о чем я говорю (черт с ними, с сайтами) есть (упрощая) язык запросов к иерархической БД[/b]. Это ты понимаешь или нет ? Язык запросов к реляционной БД существует и от того, что в БД — не зависит. А ты утверждаешь, что язык запросов к иерархической БД создать невозможно, потому как он будет зависеть, видите ли, от того, что в БД. Действительно приплыли.

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

M>>Цитирую:
M>>

M>>Продукты — дача — духовка

M>>ввиду отсутствия "дача" приведет к сообщению следующего рода

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

M>>(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть)

M>>В реальном мире все остановится на слове дача.

PD>Я не знаю, что понимается под реальным миром, но если в программе поиск в одном из узлов на уровне N заканчивается неудачей, а у нас есть еще данные на уровне N+1, то никто не мешает проверить, нельзя ли найти это слово с уровня N+1, если пройти по все вариантам уровня N

PD>Уровень N — бытовая быт домашняя
PD>Уровень N+1 духовка

PD>Ищем на уровне N "дача", N+1 — духовка. Нет дачи на уровне N. Ищем духовку на уровне N+1. Есть она там. Значит, духовка есть, но не для дачи.

Это сработает для ограниченного числа сайтов. И то, только тех, кто этот граф предоставит. Причем запрос типа "объем духовки" все равно не получится, если тот же самсунг остановится на уровне N, духовка.

M>>Описание отдыха в Анталии. А что, с точки зрения УЯЗ все хорошо: лето — отдых — анталия. А низзя. Потому-что графа нет. И не может быть

PD>От лето — скорее всего нет. А вот от страны — есть. Могу попробовать на примере какого-нибудь сайта туроператора прокрутить. Не сегодня.

Почему туроператора

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

PD>>>Дано — запущен IE, в нем about:blank
PD>>>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>>>Решение ?

M>>Заходим на http://orbitz.com/ и внимательно вдумываемся в то, что происходит при нажатии кнопки Submit.

PD>Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.

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

Кто будет просто делать XML и сразу его отсылать? Гномы с эльфами?

M>>Некий uberClient так же не сможет с нуля создать какой-либо запрос к чему-либо.

PD>А вот это неясно почему. Что, так нельзя ?

PD>client.Method = "POST";
PD>client.Text = XMLText;
PD>client.URL = "a.com";
PD>client.Send();

Кто это будет писать и вбивать? Пользователь? Нет. Тогда пользователю можно пойти на сайт и нажать на кнопочку Submit.

Некий код? Тогда если сайт не пердоставляет АПИ к своим услугам сейчас, что зхаставит его предоставлять граф потом?

PD>>>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !

M>>Зачем? Невозможно создать язык, подходящий для всех случаев.

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

На самом деле в SQL есть свои проблемы. И панацеей он тоже не является

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

PD>Ну тогда поясни, что такое может измениться на samsung.ru, чтобы мы приплыли.

Ему достаточно стать чем-то вроде youtube/lj/last.fm

С самсунгом легче, унего, в принципе, все каталогизировано. Но!

/продукты/домашние/духовка...

И? Насколько детальный этот граф будет? Что бдет после духовки?
/размер
/объем
/цвет

??

M>>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать

PD>Еще бы!

Ну так как это отличается от существующе ситуации?

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

M>Это сработает для ограниченного числа сайтов. И то, только тех, кто этот граф предоставит.

Ну пусть ограниченного. И конечно, для тех, кто этот запрос будет таким образом обрабатывать. Это само собой.

>Причем запрос типа "объем духовки" все равно не получится, если тот же самсунг остановится на уровне N, духовка.

А пусть не останавливается. Это уже вопрос к администрации сайта — что там должно быть.

M>Почему туроператора

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

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

PD>>Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.

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

Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?

M>Кто это будет писать и вбивать? Пользователь? Нет. Тогда пользователю можно пойти на сайт и нажать на кнопочку Submit.

См. выше.

M>Некий код? Тогда если сайт не пердоставляет АПИ к своим услугам сейчас, что зхаставит его предоставлять граф потом?

Дмитрий, ну сколько же можно ? Конечно, этого нет. Конечно, это делать придется. Никто не заставляет. Равно как никто не заставляет делать поиск и т.д. Если бы такое принято было бы — делали бы, хоть и не заставляют.

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

M>На самом деле в SQL есть свои проблемы. И панацеей он тоже не является

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

PD>>Ну тогда поясни, что такое может измениться на samsung.ru, чтобы мы приплыли.

M>Ему достаточно стать чем-то вроде youtube/lj/last.fm

Я так думаю, что он им никогда не станет, посколько в фирме Самсунг все же здравомыслящие люди сидят.

M>С самсунгом легче, унего, в принципе, все каталогизировано. Но!

M>/продукты/домашние/духовка...

M>И? Насколько детальный этот граф будет? Что бдет после духовки?
M>/размер
M>/объем
M>/цвет

Да. Объем там есть. Могли бы быть цвет, размер, цена и т.д.

M>>>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать

PD>>Еще бы!

M>Ну так как это отличается от существующе ситуации?

Отличается только одним — таких иерархических запросов сайты не поддерживают

>>Причем запрос типа "объем духовки" все равно не получится, если тот же самсунг остановится на уровне N, духовка.

PD>А пусть не останавливается. Это уже вопрос к администрации сайта — что там должно быть.

То есть в принципе, ровным счетом ничего не изменилось

Ну, по сравнению с текущей ситуацией

Более того, граф люьбого сайта может сильно изменяться от того, что мы думае о сайте. То есть мы думаем так:

Samsung - домашние товары - духовка
                          - стиралка
                          
        - промышленные товары - морозилка
                              - печь

А у Самсунга это на самом деле может быть

Samsung - духовка - домашняя
                  - промышленная
                  
        - морозилка - домашняя
                    - промышленная

или даже (по моделям продуктов)

Samsung - D - K - 500
                - 600
                
            - S - 400
                - 200
                
        - A - P - 620

И никто в жизни не сможет создать нормальный запрос к этому сайту

Ну если только не заниматься его reverse enginerring'ом

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

Samsung - D - K - 500 - 100
                      - 200
                      - 300
                      - 1300

Предположим, что этот граф — это граф домашней духовки, в которой ширина x длина х глубина — 100 x 200 x 300 (в миллиметрах) и объем — 1300 (в кубических сантиметрах)

Но почему именно миллиметры? Почему именно кубические сантиметры? ПОчему все это — не стоимость различных моделей?

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

А как с единицами измерения? Их много. Или ограничится какими-то основными и переизобрести XML-RPC?

PD>>>Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.

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

PD>Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?

Зачем?

Чем это будет отличаться от веб-страницы с точно таким же УРЛ и точно такой же кнопочкой?

Кстати, кто будет редактировать этот XML? Пользователь. Нет, увольте

Интерфейс построения запросов это вообзе отдельная интересная песня. Причем для большинства задач решеная как на десктопе так и на вебе:

У нас есть форма, которую пользователь заполняет, нажимает на кнопку, а что дальше с данными происходит его не волнует.

Более того, автоматически этот интерфейс сделать просто невозможно. Потому что

Samsung - D - K - 500 - 100
                      - 200
                      - 300
                      - 1300

это совсем не то, что

Daewoo - Appliances - Home - Microwaves - M-100 - 1000 cm3
                                                - 1200 cm3
                                          M-200 - 1250 cm3
                                          M-250 - 1250 cm3
                                                - 1300 cm3

Но при этом и то и другое ведут нас к тому, что нужно — домашней микроволновке объемом 1300 кубических сантиметров

M>>Некий код? Тогда если сайт не пердоставляет АПИ к своим услугам сейчас, что зхаставит его предоставлять граф потом?

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

Так оно давно принято, да никто не делает

Это и различные микроформаты, и протоколы, и спецификации. А все равно никто ничего не делает

Хотя RDF, насколько я знаю, где-то теплится (во всяком случае FOAF упоминается в LiveJournal'е)

M>>>>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать

PD>>>Еще бы!

M>>Ну так как это отличается от существующе ситуации?

PD>Отличается только одним — таких иерархических запросов сайты не поддерживают

Иерархические запросы, теоретически, это, навреное, неплохо. Но реверс инжинирить каждый сайт? Да и зачем, если есть Гугл

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

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

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

Что-то мне подсказывает, что ты даже оглавление книжки не посмотрел, на которую Sinclair ссылался. Это к слову об аргументации и воспринятии оной.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то я решил тебе не отвечать, но сделаю здесь исключение.
Спасибо.
PD>Ну тогда приплыли вообще. Можно поинтересоваться насчет web-сервисов www.samsung.com, www.microsoft.com, www.ibm.com и далее, реализующих эту функциональность ? То. что какие-то другие сервисы там могут быть — к делу не относится.
"Эту" — я полагаю, что речь идет о каталоге товаров? Нет, у этих товарищей ничего похожего нет. Надо полагать, не считают нужным публиковать такую функциональность. В связи, скорее всего, с отсутствием платежеспособного спроса.
PD>Так что если из этого исходить — приплыли, да

Совершенно верно.
S>>Задача в сделанной тобой постановке неразрешима.
PD>Доказательство. Так сказал Синклер, и выделил это жирным шрифтом.
Гм. А что тут нужно доказывать? Ты попросил решение, которое будет надежно работать несмотря ни на какие изменения структуры сайта. Теорема 1: для любого решения можно придумать такое изменение структуры, которое сделает решение неработоспособным. Доказательство полностью приводить, или и так понятно?

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

И это никак не связано с вебностью приложений.

Что здесь непонятно?

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

PD>Все остальное поскипано. По одной простой причине. Мамут со мной не согласен, но он пытается меня понять. А ты просто знаешь истину в последней инстанции и вещаешь ее.
PD>А понять не хочешь.
Оффтоп
Я хочу понять. Но ты максимально затрудняешь эту задачу. Вместо того, чтобы внятно описать весь workflow в виде, не допускающем разночтения, ты всё время ставишь какие-то непонятные задания. Это, наверное, привычка преподавателя — ничего не рассказывать, а заставлять всех самих догадываться?
Я не знаю истину в последней инстанции. Я просто пишу то, что думаю. Ок, я мог бы везде отвечать вопросом на вопрос.
Но вопросы ты тоже не любишь — когда я спрашиваю банальные вещи вроде поддержки кэширования (которая обеспечивает масштабируемость системы и определяет пригодность архитектуры к реальной работе в распределенной среде), ты начинаешь обижаться и убегать.

Я вообще достаточно хорошо всё понимаю. У меня специфика работы такая: значительную часть последних десяти лет я провел, пытаясь понять вопросы и утверждения, сформулированные в самых разнообразных видах, начиная от скана карандашного рисунка салфетки, и заканчивая детальной спецификацией веб-сервиса на бразильском португальском.

А вот ты почему-то предпочитаешь просто игнорировать всё, что тебе непонятно. Конец оффтопа.

PD> Чего хотя бы это стоит

S>>Павел, а вот тут начинается невозможная утопия. Потому, что для самсунга запросы будут одни, а для орбитза — совсем другие. Неужели так трудно понять, что невозможно придумать один язык запросов, который бы подходил и тем и тем?
PD>Еше раз поясняю: для конкретной задачи придется изобретать свой конкретный язык запросов.
Ну ты только что согласился с разработкой универсального языка запросов. Если бы ты меньше усилий тратил на критику моей манеры изложения очевидных истин и непрозрачные намеки непонятно на что, а больше тратил на внятное изложение своей позиции, то всем участникам дискуссии было бы легче.

PD>Ты хоть об одном бы подумал. Ведь то, о чем я говорю (черт с ними, с сайтами) есть (упрощая) язык запросов к иерархической БД[/b]. Это ты понимаешь или нет ?
Это я понимаю.
PD>Язык запросов к реляционной БД существует и от того, что в БД — не зависит.
Ок, движемся в конструктивную сторону. Педантично уточню, что
а) сам по себе язык запросов недостаточен для построения запросов. Для того, чтобы сделать запрос, нужно знать структуру и семантику конкретной БД. Банальное переименование колонки способно сделать твой запрос невалидным, и ни одна СУБД не станет заниматься "исправлением" ошибок.

б) если ты про SQL, то речь идет не об одном языке, а о целом семействе языков, объединенных похожим синтаксисом. Каждая СУБД использует свой диалект, который отличается от других в достаточной степени, чтобы запрос к одной не подошел к другой. И это не второстепенные детали, а суровая реальность, в которой приходится жить разработчикам.

в) язык SQL не является вычислительно полным. Особенности диалектов как раз и касаются расширений в различных областях:
— в скалярной математике. Банального возведения в степень в ANSI SQL нет
— в реляционных операциях. Классическая реляционная алгебра не позволяет, к примеру, описывать запросы с "бесконечным" количеством Join, что необходимо для некоторых алгоритмов на графах
Без этих расширений невозможно реализовать определенные запросы даже к тем данным, которые вообще удалось разместить в реляционной БД.

г) реляционная модель не является полной. Существует огромный класс приложений, данные которых невозможно адекватно отразить в БД.

Это так, к вопросу о всеобщей применимости SQL.

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

Нет. Я утверждаю, что такой язык не будет иметь практической применимости. Это разные вещи.

Ну вот тебя не смущает то, что почему-то никто не делает веб-сервисов, которые бы принимали, к примеру, SQL, и возвращали таблицы? Ведь язык есть, и существует очень давно.
Лично меня смущает, и я полагаю, что причина в том, что SQL плохо подходит для распределенной среды, когда у нас нет гарантии одновременного обновления клиента и сервера.
Может быть, структура реальных корпоративных данных плохо ложится на таблицы, а на самом деле используются деревья?
Ок, есть XPath, на котором проще описывать запросы к древовидным данным. Тем не менее, почему-то не принято делать веб-сервисы, которые бы давали исполнить XPath и возвращали NodeSet.

Есть определенные причины, по которым такие модели не добились успеха. Вместо них успеха добиваются совсем другие модели. Грубо говоря, язык запросов сейчас — HTTP.
Точно так же, как с SQL, клиенту нужно откуда-то получить знания о том, какие запросы на этом языке можно делать к данному сервису, а какие — нельзя.
Понятно, что сам по себе HTTP чрезмерно выразителен для того, чтобы как-то применять его на практике. Авторы реальных веб-сервисов принимают множество решений о том, насколько широким будет класс поддерживаемых ими запросов, и какими техническими подробностями он будет обеспечен.

Сейчас на практике набор поддерживаемых запросов искусственно сужен. К примеру, сайты, посвященные авиаперелетам, не пытаются дать тебе полный язык запросов к направленным графам. Конечно, на таком языке можно было бы сформулировать запрос "дайте мне самый дешевый перелет Омск-Мехико-Омск на такие-то даты", а также еще очень много запросов. Вместо этого они позволяют тебе выполнить, грубо говоря, ровно один запрос с параметрами: дайте мне самый дешевый перелет <А>-<B>-<A> на даты <С> и <D>.
(Я намеренно упрощаю. Под "ровно 1" имеется в виду О(1) типов запросов")

Казалось бы, это несправедливо, прямо-таки апартеид. Почему эти запросы лучше, чем другие?
Да потому, что
а) эти запросы наиболее востребованы.
Значит, заставлять клиента писать полное выражение на расширенном языке реляционной алгебры, рискуя сделать ошибку, будет не очень хорошо. Клиенту удобнее сообщить системе необходимый минимум информации.
Значит, если мы поддерживаем, допустим, четыре типа запросов, то они покрывают 92% всех потребностей. Ок, добавим пятый, и получим покрытие 99%. Остальные миллионы потенциальных запросов не принесут нам пользы, потому что нужны только редким отморозкам.
б) Эти запросы мы внимательно изучаем и оптимизируем систему так, чтобы она их эффективно выполняла.
Это очень серъезная штука. Современные веб-приложения ворочают большими объемами данных, и работают с нагрузкой, которую трудно представить программисту семидесятых.
Науке неизвестны техники оптимизации, которые бы могли дать достаточно приемлемую верхнюю оценку для стоимости произвольного запроса.
Дай мне доступ к любой базе на СУБД из первой десятки tpc-c — и я положу ее в DoS банальным select запросом.

Итого: вместо того, чтобы придумывать 1 язык, который позволяет сделать, скажем, 100 типов запросов и применять его на 10 сервисах, люди делают 10 разных языков, каждый из которых заточен на конкретные десять запросов. Это снижает затраты как клиента, так и сервиса.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>Более того, граф люьбого сайта может сильно изменяться от того, что мы думае о сайте. То есть мы думаем так:

<skipped>

То, что ты написал, и верно, и нет. Верно — в том плане, что путей может быть много и пути, заложенные Самсунгом , могут отличаться от того, что мы думаем. Но вот тут уже вопрос к разработчикам Самсунга — они должны просто предусмотреть те пути, которые пользователь может придумать. Не все, это невозможно. Но основные можно.

M>Но почему именно миллиметры? Почему именно кубические сантиметры? ПОчему все это — не стоимость различных моделей?

Что за проблема, не понимаю. В запросе указывается value="1000" unit="mm" и все.

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

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

M>А как с единицами измерения? Их много.

См. выше. Что-то я не пойму — зачем ты на ровном месте проблемы создаешь. Достаточно указать единицу измерения и все.

PD>>Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?

M>Зачем?

Чем это будет отличаться от веб-страницы с точно таким же УРЛ и точно такой же кнопочкой?

Тогда пошли этот запрос с web-страницы. Я же тебя просил дать мне способ из броузера c about:blank набрать и послать по POST некий XML на некий URL.

M>Иерархические запросы, теоретически, это, навреное, неплохо. Но реверс инжинирить каждый сайт? Да и зачем, если есть Гугл

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

Ладно, давай заканчивать. В общем, ситуация ясная — кое с чем ты согласен, но убедить тебя я в целом не смог. Некоторые твои аргументы меня не убеждают, к другим стоит отнестись более серьезно.

В заключение пару слов на тему о том "этого нет и потому не нужно". Лично мое мнение на этот счет таково. Идея web , в тот момент, когда она была сформулирована, исходила из состояния дел на тот момент. ИМХО это была идея всемирной паутины, не более. Но начав жить своей жтзнью (а идея оказалась очень плодотворной), она начала утверждать законы, исходя из своей собственной модели. Грубо говоря, она начала отвергать все, что в эту модель плохо укладывается и продвигать то, что укладывается хорошо.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тогда пошли этот запрос с web-страницы. Я же тебя просил дать мне способ из броузера c about:blank набрать и послать по POST некий XML на некий URL.
Павел, ты почему-то всё время подменяешь фундаментальные вопросы, касающиеся этого языка, на какие-то несущественные подробности вроде "послать по POST некий XML на некий URL", причем непременно с about:blank.

Вопросы о том, какой будет транспорт для запросов и ответов на этом языке, вообще говоря вторичен.

Ты до сих пор ничего не сказал о том, какие запросы ты собираешься выполнять. Так, пара неинформативных примеров.

Вот, например, XPath вводит кучу понятий: node, element, attribute, value, node-set.

У тебя какая структура модели, по которой выполняются запросы? Остовное дерево? Произвольный граф? Что в вершинах этого графа? Что в листьях этого дерева?
Какие предикаты предполагается вычислять?
Какие будут типы данных? Скаляры/кортежи/множества скаляров/множества кортежей/упорядоченные множества/графы?
Какие операции предполагается поддерживать над этими типами данных? Какова алгебра этих операций?
Чем этот язык будет лучше, чем SQL, OCL, OQL, XPath, CSS?

Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>У тебя какая структура модели, по которой выполняются запросы? Остовное дерево? Произвольный граф? Что в вершинах этого графа? Что в листьях этого дерева?
S>Какие предикаты предполагается вычислять?
S>Какие будут типы данных? Скаляры/кортежи/множества скаляров/множества кортежей/упорядоченные множества/графы?
S>Какие операции предполагается поддерживать над этими типами данных? Какова алгебра этих операций?

Вот это уже вопросы по существу. Итак, сам принцип уже не осуждается, а задается конкретный вопрос о том, как будет выглядет запрос и т.д.

Ответа дать не могу. Потому что для того, чтобы его дать, я должен потратить не меньше времени, чем, к примеру, потребовалось разработчикам SQL или XML. Потому что это не проще, а скорее сложнее. Может, тут действительно что-то из XPath можно будет взять, может, что-то иное. Вообще-то языки запросов к иерархическим БД существовали еще в 70-е годы, см, например

http://en.wikipedia.org/wiki/Data_Language/1

S>Чем этот язык будет лучше, чем SQL, OCL, OQL, XPath, CSS?

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

S>Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?

Куда POST — вполне понятно. Какой XML — пусть и непонятно. Но послать-то можно или нет ? Пусть безотносительно к тому, что я писал, просто так вопрос сформулируем — можно ли из броузера послать сразу POST запрос на некий URL ? GET — элементарно, а вот POST ? Кто его там примет — сейчас не важно. И, пожалуйста, без разговоров о том, зачем. Просто — можно или нет ?

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

PD>Вот это уже вопросы по существу. Итак, сам принцип уже не осуждается, а задается конкретный вопрос о том, как будет выглядет запрос и т.д.

PD>Ответа дать не могу.
Ну тогда что мы здесь обсуждаем? "У меня идея: давайте что-нибудь придумаем"?
PD>Потому что для того, чтобы его дать, я должен потратить не меньше времени, чем, к примеру, потребовалось разработчикам SQL или XML.
Вообще-то определиться с базовыми понятиями можно за день-другой.

PD>Потому что это не проще, а скорее сложнее. Может, тут действительно что-то из XPath можно будет взять, может, что-то иное. Вообще-то языки запросов к иерархическим БД существовали еще в 70-е годы, см, например
PD>http://en.wikipedia.org/wiki/Data_Language/1
Я в курсе. Я вообще задавался вопросом о языках запросов — когда еще собирался писать дисер.

S>>Чем этот язык будет лучше, чем SQL, OCL, OQL, XPath, CSS?
PD>Вообще говоря, язык меня интересует, но во вторую очередь. Если будут иерархические запросы (а их нет) — будет и язык.

Жан Марк Натюр, известный французский художник-портретист, долгое время не мог схватить сходство с португальским послом, которого как раз рисовал. Расстроенный неудачей, он уже собирался бросить работу, но перспектива высокого гонорара склонила его к дальнейшим попыткам добиться сходства. Когда портрет близился к завершению и сходство было уже почти достигнуто, португальский посол покинул Францию, и портрет остался с несхваченным сходством.

Натюр продал его очень выгодно, но с этого времени решил сначала схватывать сходство и только потом приступать к написанию портрета

Ты тоже сначала хочешь запросы, а потом — язык? Как это? Если ты про конкретный синтаксис — я тебя о нем пока и не спрашивал. Рано пока придумывать синтаксис — нужно сначала определиться с семантикой. Если у тебя нет представления о семантике запросов — то говорить в этой ветке как бы не о чем.

S>>Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?

PD>Куда POST — вполне понятно. Какой XML — пусть и непонятно. Но послать-то можно или нет ? Пусть безотносительно к тому, что я писал, просто так вопрос сформулируем — можно ли из броузера послать сразу POST запрос на некий URL ? GET — элементарно, а вот POST ? Кто его там примет — сейчас не важно. И, пожалуйста, без разговоров о том, зачем. Просто — можно или нет ?
Можно. Читать про тег <form>, а также про XmlHttpRequest.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

Так, все, этот ответ последний.

>Теорема 1: для любого решения можно придумать такое изменение структуры, которое сделает решение неработоспособным. Доказательство полностью приводить, или и так понятно?

Подменяем понятия, что для тебя характерно. Твоя теорема 1 безупречна, так как она ни о чем. Естественно, если сайт о микроволновках стал сайтом о космических ракетах, то тут уж точно, что ни делай, решение станет неработоспособным.

А вот такую теорему берешься доказать

Теорема 2: для любого решения можно придумать такое изменение внутренней структуры, не влияющее на внешний интерфейс, которое сделает решение неработоспособным.

Если готов согласиться с теоремой 2 — приведи доказательства. Но не думаю, что согласишься, ибо этим половину принципов ООП похоронишь.

А ведь об этом речь и шла.

S>Я вообще достаточно хорошо всё понимаю. У меня специфика работы такая: значительную часть последних десяти лет я провел, пытаясь понять вопросы и утверждения, сформулированные в самых разнообразных видах, начиная от скана карандашного рисунка салфетки, и заканчивая детальной спецификацией веб-сервиса на бразильском португальском.

И что из этого следует ? Я последние десять лет занимался примерно тем же, правда без бразильского португальского и без салфеток. Но из этого я не стану делать выводы, что я хорошо все понимаю. К примеру, в банаховых пространствах я так-таки ничего и не понимаю. Ты уверен почему-то, что все понимаешь хорошо. Бога ради, но почему я должен этому верить ?

S>Ну ты только что согласился с разработкой универсального языка запросов.

Мамуту захотелось так его назвать, я не стал спорить. Называй его УЯЗ или как-то иначе — мне это все равно. Если угодно, можешь назвать SQL УЯЗ/РБД, и это будет верно.

PD>>Ты хоть об одном бы подумал. Ведь то, о чем я говорю (черт с ними, с сайтами) есть (упрощая) язык запросов к иерархической БД[/b]. Это ты понимаешь или нет ?
S>Это я понимаю.
PD>>Язык запросов к реляционной БД существует и от того, что в БД — не зависит.
S>Ок, движемся в конструктивную сторону. Педантично уточню, что
S>а) сам по себе язык запросов недостаточен для построения запросов. Для того, чтобы сделать запрос, нужно знать структуру и семантику конкретной БД. Банальное переименование колонки способно сделать твой запрос невалидным, и ни одна СУБД не станет заниматься "исправлением" ошибок.

Естественно. Для этого есть запрос схемы БД, я об этом писал. По схеме можно граф построить. А семантика — да, за кадром, как всегда, об этом я тоже писал.

S>б) если ты про SQL, то речь идет не об одном языке, а о целом семействе языков, объединенных похожим синтаксисом. Каждая СУБД использует свой диалект, который отличается от других в достаточной степени, чтобы запрос к одной не подошел к другой. И это не второстепенные детали, а суровая реальность, в которой приходится жить разработчикам.

Ну это уже совсем бог знает что началось. Какое мне дело до различных реализации SQL и при чем это тут вообще ?

S>в) язык SQL не является вычислительно полным. Особенности диалектов как раз и касаются расширений в различных областях:
S> — в скалярной математике. Банального возведения в степень в ANSI SQL нет
S> — в реляционных операциях. Классическая реляционная алгебра не позволяет, к примеру, описывать запросы с "бесконечным" количеством Join, что необходимо для некоторых алгоритмов на графах
S>Без этих расширений невозможно реализовать определенные запросы даже к тем данным, которые вообще удалось разместить в реляционной БД.

Это все в Recycled Bin как не имеющее к делу отношения.

S>г) реляционная модель не является полной. Существует огромный класс приложений, данные которых невозможно адекватно отразить в БД.

Туда же.

S>Это так, к вопросу о всеобщей применимости SQL.

S>Ну вот тебя не смущает то, что почему-то никто не делает веб-сервисов, которые бы принимали, к примеру, SQL, и возвращали таблицы? Ведь язык есть, и существует очень давно.

S>Лично меня смущает, и я полагаю, что причина в том, что SQL плохо подходит для распределенной среды, когда у нас нет гарантии одновременного обновления клиента и сервера.

Совершенно верно. Но я и не предлагаю в своей модели ничего вставлять или изменять с клиента, еще этого не хватало

. А если бы РБД была констатной и из SQL можно было бы только SELECT использовать — почему бы и нет ?

Ладно, все, хватит, нет у меня уже времени обсуждать все с начала

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

S>Ты тоже сначала хочешь запросы, а потом — язык? Как это? Если ты про конкретный синтаксис — я тебя о нем пока и не спрашивал. Рано пока придумывать синтаксис — нужно сначала определиться с семантикой. Если у тебя нет представления о семантике запросов — то говорить в этой ветке как бы не о чем.

Ну и слава богу.

S>>>Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?

PD>>Куда POST — вполне понятно. Какой XML — пусть и непонятно. Но послать-то можно или нет ? Пусть безотносительно к тому, что я писал, просто так вопрос сформулируем — можно ли из броузера послать сразу POST запрос на некий URL ? GET — элементарно, а вот POST ? Кто его там примет — сейчас не важно. И, пожалуйста, без разговоров о том, зачем. Просто — можно или нет ?
S>Можно. Читать про тег <form>, а также про XmlHttpRequest.

Опять та же песня. Я тебя спрашиваю — как из броузера пользователю послать запрос , а ты меня к классам отсылаешь и к HTML. Ну как с тобой говорить после этого!

Еще раз точно определяю задачу. Я — юзер. Я HTML не знаю, тем более какие-то классы.
Я запустил IE7. В окне about:blank
Я имею некий файл, в котором XML (а впрочем, все равно, что там)
Я хочу послать этот файл на сервер a.com (с помощью POST).
Что там с ним сделают — не имеет сейчас значения.
Все.

Решение

1. Ты должен сделать следующее
1.1 Нажать то-то и то-то и т.д.

или

Решения нет.

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

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

S>>У тебя какая структура модели, по которой выполняются запросы? Остовное дерево? Произвольный граф? Что в вершинах этого графа? Что в листьях этого дерева?
S>>Какие предикаты предполагается вычислять?
S>>Какие будут типы данных? Скаляры/кортежи/множества скаляров/множества кортежей/упорядоченные множества/графы?
S>>Какие операции предполагается поддерживать над этими типами данных? Какова алгебра этих операций?

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

Жили были мыши. И все их обижали. И лисы, и кошки, и совы и даже собаки. И тогда они пошли к мудрому филину за помощью и попросились:
— Мудрый филин, помоги нам — нас все обижают — и лисы, и кошки, и совы и даже собаки. Жить невозможно, скажи, что нам сделать?
Подумал мудрый филин и сказал:
— Интересная проблема. Но я могу ее решить — вы просто станьте ежиками. У ежиков иголки, вас никто обижать и не будет!
Обрадовались мыши, поблагодарили мудрого филина и побежали радостные домой. И вот бегут, бегут, и вдруг одна мышь и говорит:
— Постойте, постойте, а КАК мы сможем стать ежиками?
Задумались мыши и побежали опять к мудрому филину:
— Мудрый филин, а скажи, КАК нам стать ежиками?
— Мыши, вот только грузите меня херней — я стратегией занимаюсь!

З.Ы. Павел, ассоциация с этим анекдотом у меня выстроилась в целом по прочтении многих твоих постов. Очень хорошо, когда строится универсальный суперязык и такая система, которая сразу все найдет и поймет вопрос от любого пользователя. Интересная тема, головокружительные перспективы. Но как только встают вопросы хотя бы примерной практической реализации, с указанием слабых мест, например такая мелочь как бесконечные (с практической точки зрения) варианты для перебора — это все несущественная тактика, как нибудь само решится...

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Опять та же песня. Я тебя спрашиваю — как из броузера пользователю послать запрос

PD>, а ты меня к классам отсылаешь и к HTML. Ну как с тобой говорить после этого!
Нормально говорить. Задавать вопросы, если что-то непонятно. Рассказывать, если что-то понятно.

PD>Еще раз точно определяю задачу. Я — юзер. Я HTML не знаю, тем более какие-то классы.
PD>Я запустил IE7. В окне about:blank
PD>Я имею некий файл, в котором XML (а впрочем, все равно, что там)
PD>Я хочу послать этот файл на сервер a.com (с помощью POST).
PD>Что там с ним сделают — не имеет сейчас значения.
PD>Все.

PD>Решение

PD>1. Ты должен сделать следующее
1. Набрать в адресной строке браузера a.com
2. Найти на сайте (при помощи прочтения документов глазами, понимания их мозгом, и манипуляций мышкой) форму, в которой будет предусмотрен интерфейс по запросу от тебя файлв
3. Воспользоваться кнопочкой browse для выбора файла
4. Воспользоваться кнопочкой submit для отправки файла.
Всё? Или есть какие-то еще ограничения, которые ты забыл упомянуть, чтобы уж с гарантией сделать задачу неразрешимой?

З.Ы. Павел, пытаясь формулировать вот такие идиотские задания, ты не получишь ни славы на форумах, ни понимания того, как правильно проектировать веб-приложения и веб-сервисы.
Если тебе почему-то неочевидно, что твое задание — это верх идиотизма, то я поясню.
Дело в том, что ты выступаешь от имени юзера, который не знает HTML. Так? Ну тогда откуда у тебя желание отправить файл при помощи POST? Откуда ты вообще узнал про протокол HTTP и метод POST в нем? Откуда ты такой взялся, что знаешь, что такое XML, но не знаешь HTML?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

PD>Подменяем понятия, что для тебя характерно. Твоя теорема 1 безупречна, так как она ни о чем.
Павел, ни о чем — это твоя задача. Цитирую:

предлагаю построить такой запрос

Дайте объем микроволновой печи ce287mnr.

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

PD>Естественно, если сайт о микроволновках стал сайтом о космических ракетах, то тут уж точно, что ни делай, решение станет неработоспособным.
Нет, Павел, сайт не стал о космических ракетах. Компания Самсунг всего лишь выделила микроволновки для россии в отдельную линейку, которая теперь доступна по-другому, а вместо HTML стала отдавать Flash. Плита с производства всё еще не снята, но данные о ней устроены совершенно другим образом. Вполне, впрочем, читаемым для человека.

PD>А вот такую теорему берешься доказать

PD>Теорема 2: для любого решения можно придумать такое изменение внутренней структуры, не влияющее на внешний интерфейс, которое сделает решение неработоспособным.
Нет, не берусь. Я ее и сформулировать не берусь, потому что она оперирует таким неуловимым понятием, как "внутренняя структура", и таким неопределенным, как "внешний интерфейс".
И потому, что к твоей задаче (см. выше) эта теорема никакого отношения не имеет. Если мы запретили самсунгу менять внешний интерфейс, то всё сразу приходит в порядок.
Но мы этого сделать не можем.
PD>А ведь об этом речь и шла.
Нет, Павел, речь уже о чем только ни шла.

PD>И что из этого следует ? Я последние десять лет занимался примерно тем же, правда без бразильского португальского и без салфеток. Но из этого я не стану делать выводы, что я хорошо все понимаю. К примеру, в банаховых пространствах я так-таки ничего и не понимаю.
Зачем заниматься передергиванием? Я имел в виду способность понять объяснение, а не заранее полученное знание. Или ты имеешь в виду, что ты в принципе не способен понять банаховы пространства, как бы тебе их ни объясняли? (Кстати, ничего особенного в банаховых пространствах нет. Что именно тебе непонятно — полнота, нормированность, или тебе сам термин векторное пространство непонятен?)

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

S>>Ок, движемся в конструктивную сторону. Педантично уточню, что
S>>а) сам по себе язык запросов недостаточен для построения запросов. Для того, чтобы сделать запрос, нужно знать структуру и семантику конкретной БД. Банальное переименование колонки способно сделать твой запрос невалидным, и ни одна СУБД не станет заниматься "исправлением" ошибок.

PD>Естественно. Для этого есть запрос схемы БД, я об этом писал.
Вообще-то об этом писал я. А ты считал это несущественным, цитирую:

А теперь рассмотрим SQL-сервер. Это тоже сервер , но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов
Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.

PD>Ну это уже совсем бог знает что началось. Какое мне дело до различных реализации SQL и при чем это тут вообще ?
При том, Павел, что не удается придумать один SQL на все случаи жизни. Мы имеем дело с большим количеством разных SQL.

PD>Туда же.
Отлично. Вот сразу видно, где проходит граница понимания. То, что не укладывается в твою голову, ты смело отправляешь в dev/null. И при этом у тебя хватает наглости обвинять меня в том, что я как-то неправильно спорю.

S>>Лично меня смущает, и я полагаю, что причина в том, что SQL плохо подходит для распределенной среды, когда у нас нет гарантии одновременного обновления клиента и сервера.

PD>Совершенно верно. Но я и не предлагаю в своей модели ничего вставлять или изменять с клиента, еще этого не хватало

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

PD>А если бы РБД была констатной и из SQL можно было бы только SELECT использовать — почему бы и нет ?
Если бы сайт Самсунга был константным, мы бы вернулись к решению с парсингом HTML. Но он меняется во времени — это условие задачи.

... << RSDN@Home 1.2.0 alpha rev. 677>>

M>>Более того, граф люьбого сайта может сильно изменяться от того, что мы думае о сайте. То есть мы думаем так:

PD><skipped>

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

Угу, и кто этим будет заниматься, этим представлением? Я вот не напрягаясь придумал три способа предсатвления товаров для самсунга. Это при том, что ни одна из этих моделей даже близко может быть не похожа на то, как эта информация хранится на сервере/серверах самсунга.

И что такое "основные"? Для Самсунга может быть только одно основное — разделение по моделям товара. Кто их заставит предоставлять N графов?

M>>Но почему именно миллиметры? Почему именно кубические сантиметры? ПОчему все это — не стоимость различных моделей?

PD>Что за проблема, не понимаю. В запросе указывается value="1000" unit="mm" и все.

То есть мы все равно собираемся ограничить количество ключевых слов?

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

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

Неьольшой словарный запас, который подходит для чего?

Для того же Самсунга это моет быть:
— размеры (в миллиметрах для мелких деталей, в сантиметрах — для больших)
— объем (микроволновки)
— вместимость (стиральные машины)
— разрешение (мониторы, телевизоры)
— вес (для всего кроме миксеров, например)
— грузоподъемность (для тракторов)
— тоннаж (для кораблей)
— водоизмещение (для кораблей)
— предельное давление на грунт (для машин)

и т.д. и т.п.

M>>А как с единицами измерения? Их много.

PD>См. выше. Что-то я не пойму — зачем ты на ровном месте проблемы создаешь. Достаточно указать единицу измерения и все.

Какую единицу и для чего? В чем будем измерять водоизмещение яхты и объем микроволновки? Как мы будем указывать, что то или иное значение — это именно водоизмещение, а не объем?

PD>>>Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?

M>>Зачем?

Чем это будет отличаться от веб-страницы с точно таким же УРЛ и точно такой же кнопочкой?

PD>Тогда пошли этот запрос с web-страницы. Я же тебя просил дать мне способ из броузера c about:blank набрать и послать по POST некий XML на некий URL.

Еще раз:

Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?

Чем это отличается от

Заходим на http://orbitz.com/ , заполняем форму и нажимаем на кнопку Submit.

?????

M>>Иерархические запросы, теоретически, это, навреное, неплохо. Но реверс инжинирить каждый сайт? Да и зачем, если есть Гугл

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

Должны делать что? Граф? И? Этот граф — он же не универсален. Для того, чтобы смочь сделать к нему запрос, надо знать, что значит каждый из элементов этого графа, нет?


Конечный пользователь
           
           Форма составления запроса

                       Запрос в неком формате
                                   
                                   Граф сайта 1
                                   Граф сайта 2
                       
                       Ответ в неком формате
          
           Форма ответа
           
Конечный пользователь

Графы сайтов у нас выглядят так:

Samsung - D - K - 500 - 100
                      - 200
                      - 300
                      - 1300

Daewoo - Appliances - Home - Microwaves - M-100 - 1000 cm3
                                                - 1200 cm3
                                          M-200 - 1250 cm3
                                          M-250 - 1250 cm3
                                                - 1300 cm3

Возникают следующие вопросы:

— Откуда пользователь знает, что D-K-500-1300 и Daewoo-Appliances-Home-Microwaves-M-250-1300 — это два графа для аналогичных товаров. А он обязан это знать, иначе он никогда не сможет создать запрос к этим двум сайтам

Да никак. Ему придется выкачать весь граф сайта, вручную его проанализировать (ревер-инжинирнуть), понять, что к чему, и только потом составить какой-то запрос. Запрос ему уже не придется составлять, потому что после анализа графа он и так будет знать, что к чему

Более того,

Теперь запрос

Продукты — быт — духовка

ведет нас прямым образом на

http://www.samsung.ru/products/home/microwave/

никуда не приведет. Потому что такие понятия, как быт и духовка у самсунга будут просто отсутствовать, а присутствовать только в описании товара, которое (по аналогии с блогами) в графе не участвует, потмоу что это просто текст.

По аналогии с базами данных. Мы не можем составить произвольный запрос к произвольной базе данных, потому что:

— мы не знаем структуры базы
— если мы знаем структуру, то
-- мы не знаем назначение таблиц и взаимоотношения между ними
-- мы не знаем назначение полей в таблицах и взаимоотношения между ними

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

То же и с гипотетическим языком запросов к сайтам.

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>

	От:	Pavel Dvorkin
	Дата:	01.04.08 04:04
	Оценка:	8 (3) +1

От:	Fox007	http://nalobin.ru
Дата:	01.04.08 06:47
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	01.04.08 07:12
Оценка:	+2

	От:	Pavel Dvorkin
	Дата:	01.04.08 07:23
	Оценка:

	От:	Pavel Dvorkin
	Дата:	01.04.08 07:33
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	01.04.08 18:13
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	02.04.08 05:12
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	02.04.08 10:01
Оценка:	+1

	От:	fmiracle
	Дата:	03.04.08 05:30
	Оценка:	52 (5) +1

	От:	WolfHound
	Дата:	03.04.08 15:46
	Оценка:	15 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	03.04.08 22:04
Оценка: