M>>Свежо предание, да верится с трудом Думаю, разработчики Java-приложений много могут рассказать о цене такой переносимости

dmz>самые популярные десктоп-приложения на джаве — это среды разработки для джавы.



Про мобильные приложения можно умолчать — полностью переносимых не так много, как хотелось бы

Здравствуйте, 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 доступен через веб-интерфейс и на тех же телефонах, например

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

dmz>Фигня какая-то. Сервер мы напишем на эрланге, и развернем на кластере из пятка машин. Когда клиентов станет столько, что кластер станет плохо, это будет значить, что нас совершенно немвеняемое количество клиентов, и Гугл с остальными уже стоят в очереди, что бы нас купить, а инвестор отвалил денег еще на пару сотен серверов для кластера.
Только эрланг я бы использовать не стал.
У нас его на одном проекте используют... раз в 2 месяца находят баги в рантайме... недавно его хваленая кластеризация глючила (подробности не выяснял) либы тоже сырые.
Так что жаба или .NET тут будут самое то. Они по крайней мере работают. А кластер всеравно придется очень хорошо продумывать ибо под большой нагрузкой любая автоматика расчитанная на некий общий случай в вакууме дохнет.

dmz>>Фигня какая-то. Сервер мы напишем на эрланге, и развернем на кластере из пятка машин. Когда клиентов станет столько, что кластер станет плохо, это будет значить, что нас совершенно немвеняемое количество клиентов, и Гугл с остальными уже стоят в очереди, что бы нас купить, а инвестор отвалил денег еще на пару сотен серверов для кластера.
WH>Только эрланг я бы использовать не стал.
WH>У нас его на одном проекте используют... раз в 2 месяца находят баги в рантайме...

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

F>>В своем новоиспечённом протоколе ты подменил транспортный протокол HTTP на протокол, реализующий подмножество свойств HTTP с request и response целиком в формате XML + протокол непосредственно уровня приложения.

PD>Маленький вопросик можно ? А если посылать по SMTP — это тоже будет request и response ? Или это свойства исключительно HTTP ? Или любой запрос есть request, а ответ — response , независимо от протокола ?
Ну и вопросы у тебя. Сам то понял что спросил? Request и response это английские слова, которые в русское языке звучат как "запрос" и "ответ" . Именно в этом контексте эти слова и следует понимать в моих сообщениях. Привязки к конкретным протоколам эти слова не имеют.

>>О вреде придумывания своего транспортного протокола для непоточной передачи данных — смотри моё предыдущее сообщение.
PD>О господи! Теперь уже предлагаемый мой протокол стал транспортным! Скоро, он, видимо, в твоей интерпретации физическим станет.
Давай будем отталкиваться от того что написано, а не от того что "станет в моей интерпретации".

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

PD>Не придется. Он сам обновится. Поставь себе Mozilla или FireFox и жди. Как только новая версия появится, предложат обновить. И Windows Update так же работает, только не всю ОС (слава богу . а лишь кое-что заменяет. И я даже не знаю, что именно.

Сижу на работе, отлыниваю от оной в рсдн — и вдруг бац — окно — "давай обновил фирефокс"! Я так, радостно, давай, только дочитаю и сразу обновим!
Прихожу домой, захожу почитать анекдоты — бац, давай обновим фирефокс! Вот, блин, вроде ж обновлял? А, то на работе было, ну давай, давай.
ну а за компом жены уже симптомы дежавю проявляются.
Хорошо хоть ноута у меня нет.

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

Здравствуйте, 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 которого совершенно нечитаем.

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

AVK>Очень опрометчивое утверждение, по крайней мере без указания того, что это за приложения. Вот у меня прямо сейчас открыты в студии два приложения, выполняющие абсолютно идентичные задачи, а именно RSDN@Home и rsdn.ru. На одну и ту же единицу функционала в первом случае усилий затрачивается сильно меньше (еще бы там код в свое время не превратили местами в каку ).

Ну вероятно, надо сделать какие-то оговорки относительно характера приложений; те приложения которые плохо вмещаются в возможности HTML/JS — это проблемы. Просто топик уже весь мозг разрушил, не до оговорок.

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

И т.п. согласитесь, тут есть существенные отличия от standalone приложений.

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

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

Я вот в июне прокатился по Европе и понял, что архитектура поезда гораздо удобнее для пользователя, чем у самолета.
Вот смотри: я доехал от Амстердама до Франкфурта за 4 часа.
При этом я уезжал из центра, и приехал в центр.
Предположим, что я попытался бы полететь на быстром-быстром самолете. Ок, сам полет там часа полтора. Процедура регистрации, предполетного досмотра и посадки занимает еще около 1.5 часов (и, кстати, весьма малоприятна). При этом я должен еще добраться из центра в аэропорт — а он на отшибе, даже в самых удобных европейских городах я не доберусь до аэропорта быстрее, чем за полчаса. Итого мы получили те же 4 часа, проведенные в суете и беготне. И это еще оптимистично — пробки могут сожрать и полтора часа на дорогу в аэропорт, к тому же мало кто рискует выезжать "впритык".

Это я к тому, что всё надо осматривать критически. Хотя в нашем с тобой споре про приложения ты занимаешь позицию твоего друга машиниста. Потому, что пытаешься защищать архитектуру, сложившуюся в до-веб эпоху, и игнорировать достижения прогресса. Мне смешно читать все эти "ах, если бы была такая среда, которая бы волшебно работала на всех машинах" — есть такая среда. Даже две: Javascript и Java.
При этом ты считаешь Java безусловно превосходящей технологией для клиента (забывая пояснить — почему), и почему-то не хочешь обращать внимание на то, что она так и не смогла заработать на десктопе. Вместо того, чтобы напрячь мозг и подумать, чем таким отличается Javascript, что приложения на нем превосходят Java по распространенности примерно как 10000:1, ты начинаешь придумывать всякие глупости типа "а вдруг веб-страница захочет сделать глобальный перехват клавиатуры".
Мне смешно читать все эти "ах, если бы был такой протокол удаленных вызовов, построенный на XML, и был язык его описания, и генератор клиентского и серверного кода по этому описанию". Потому, что вот есть SOAP, и за последние три года его наелись все по самое не хочу, и обнаружили в нем кучу недостатков. А ты вместо того, чтобы понять, за что критикуют SOAP, ты заново изобретаешь какой-то его вариант, который заведомо хуже продуман, зато тщательно копирует архитектурные просчеты SOAP. Зачем?

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 быть в то же время протоколом запроса. При необходимости.
Неоходимости медитировать нет, ибо всё уже сказано. Кто не понял — сам виноват.