Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А может , он прав ? Я вот на майские праздники в поездку собрался, самолетом. Может, пока еще не поздно, паровоз заказать ?
Если Вы собираетесь этот самолет строить самостоятельно, то лучше закажите паровоз.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Mamut, Вы писали:
M>На каком компьютере
на клиентском.
>под управлением какой операционной системы?
Установленной на нем.
>Что буем делать с мобильными системами?
А там ничего-таки нет ? Загрузи какой-нибудь tetris в свой мобильный телефон. Если он сумеет и ему будет разрешено выходить в Интернет через мобильную связь — вот тебе и это приложение. ОС, вообще-то, в классическом смысле, не обязательна.
PD>А может , он прав ? Я вот на майские праздники в поездку собрался, самолетом. Может, пока еще не поздно, паровоз заказать ?
PD>P.S. Просьба не принимать все сказанное всерьез.
Если его паровоз при этом может произвольно перемешщаться в пространстве со скоростью 850 км/ч, тогда к его аргументам имело бы смысл прислушаться.
Впрочем, паровоз еще умеет возить в десять раз больше людей и грузов, чем самолет.
Ваш самолет это умеет? Что-то принципально новое? Или он позволит что-то делать на порядок лучше, как самолет vs паровоз?
Где преимущества? Мы ждем.
Вот если бы вы обсуждали преимущества протокола для квантовых каналов связи vs XML over HTTP — нам бы крыть было бы нечем.
Так вот — преимущества?
Может, потом на что-то и отвечу, пока только маленькое замечание
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 конечно выигрывает , т.к. вообще нет понятия совместимости.
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 для данного сервиса?
dmz>Конечно. Реализаций HTTP клиентов и серверов много, и если не заработает с одной реализацией, то заработает с другой. dmz>А вот что мне делать, если единственная имеющаяся для языка реализация SOAP клиента не работает с данным конкретным SOAP-сервером?
dmz>Это я пример из жизни привожу. При этом, SOAP сложный, за три дня на коленке клиента не переписать.
А весь и не надо в каждом конкретном случае. Неужели, любой другой XML формат всегда легче реализовать чем SOAP?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>На каком компьютере
PD>на клиентском.
>>под управлением какой операционной системы?
PD>Установленной на нем.
>>Что буем делать с мобильными системами?
PD>А там ничего-таки нет ? Загрузи какой-нибудь tetris в свой мобильный телефон. Если он сумеет и ему будет разрешено выходить в Интернет через мобильную связь — вот тебе и это приложение. ОС, вообще-то, в классическом смысле, не обязательна.
Что-то я не вижу вагона приложений, которые без проблем работют хотя бы под 3-мя настольными и 1-2-мя мобильными операционными системами. А вдеь мы говорим о сложном приложении, работающим с нашим сервисом на любой платформе и предоставляющим одинаковые возможности под всеми платформами
Скайп в счет не берем, Скайп под Линуксом — это совсем не тот Скайп, что под Виндой
Мозиллу в счет не берем, на мобильных платформах ее нет
Остается только Опера. И то, разработчикам Оперы надо ставить памятник при жизни за такое достижение
И в это же время мое веб-приложение http://janus.dmitriid.com/ работает даже на таких платформах, о которых я ни сном ни духом
Здравствуйте, 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 каком-нибудь) и расказать об удобстве использования
M>И в это же время мое веб-приложение http://janus.dmitriid.com/ работает даже на таких платформах, о которых я ни сном ни духом
Все верно. Только задумайся еще — почему ? Ответ простой — потому что развитие в последние годв шло по этому пути. Если бы в свое время оно пошло по пути создания некоего промежуточного слоя между языком программирования и ОС, мы бы имели сейчас совсем другую картину. И приступая к разработке , ты бы знал, что оно должно будет работать под разными платформами. Но тебя бы это сильно не напрягало. Как не очень напрягает разработчиков сайтов под Java, которые сами по себе есть десктопные приложения, а работают под разными платформами. Все вопросы связанные с платформой, берет на себя Sun в своей VM.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
PD>>>Так я уже 10 раз объяснил — не должно быть специальных web-приложений. Должны быть просто приложения, взаимодействующие с Интернет-миром и в то же время умеющие использовать все возможности компьютера.
M>>Говорить, что все веб-приложения — отстой, вместо них должны бть только десктоп-приложения так же неверно, как и говорить обратное
PD>Ну я не знаю, как уже объяснять. Я ясно говорю — есть просто приложения, с той или иной степенью web (точнее, Интернет) компоненты. Мне опять в ответ — все веб-приложения — отстой, вместо них должны быть только десктоп-приложения ? Что за ерунда ?
Не мы это начали Так и не было услышано ни единого аргумента, который однозначно бы доказывал, что существующая модель с веб-браузером в качестве среды выполнения плоха. Особенно на данный момент
C>Переносимость веб-приложений тоже не надо идиализировать. Попробуйте открыть новостной сайт (без специально адаптированной версии) открыть на среднестатистическом телефоне (а не на iPhone каком-нибудь) и расказать об удобстве использования
M>>И в это же время мое веб-приложение http://janus.dmitriid.com/ работает даже на таких платформах, о которых я ни сном ни духом
PD>Все верно. Только задумайся еще — почему ? Ответ простой — потому что развитие в последние годв шло по этому пути. Если бы в свое время оно пошло по пути создания некоего промежуточного слоя между языком программирования и ОС, мы бы имели сейчас совсем другую картину. И приступая к разработке , ты бы знал, что оно должно будет работать под разными платформами. Но тебя бы это сильно не напрягало. Как не очень напрягает разработчиков сайтов под Java, которые сами по себе есть десктопные приложения, а работают под разными платформами. Все вопросы связанные с платформой, берет на себя Sun в своей VM.
Свежо предание, да верится с трудом Думаю, разработчики Java-приложений много могут рассказать о цене такой переносимости
А вот веб-приложения как раз такой прослойкой и являются И я знаю, что оно работает под разными платформами
PD>>Все верно. Только задумайся еще — почему ? Ответ простой — потому что развитие в последние годв шло по этому пути. Если бы в свое время оно пошло по пути создания некоего промежуточного слоя между языком программирования и ОС, мы бы имели сейчас совсем другую картину. И приступая к разработке , ты бы знал, что оно должно будет работать под разными платформами. Но тебя бы это сильно не напрягало. Как не очень напрягает разработчиков сайтов под Java, которые сами по себе есть десктопные приложения, а работают под разными платформами. Все вопросы связанные с платформой, берет на себя Sun в своей VM.
M>Свежо предание, да верится с трудом Думаю, разработчики Java-приложений много могут рассказать о цене такой переносимости
самые популярные десктоп-приложения на джаве — это среды разработки для джавы.
Здравствуйте, Curufinwe, Вы писали:
M>>На самом деле существует некоторый порог переносимости, но он гораздо ниже, чем у десктоп приложений
C>Согласен. Особенно это касается простых веб приложений.
...я бы уточнил. примитивных.
хочеца большего — как пример — качай java applet для gmail
. 
Не выбрасывают же STL только потому, что самому можно сделать реализацию, которая будет в конкретном случае на 10% быстрее. 
