Ммм, я не буду вчитываться, давайте я предположу — смысл в том, что при наличии транзакции 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 в конце концов пришли к одному и тому же. А поэтому замкну я этот кусочек дерева и сделаю граф.
Здравствуйте, 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 — я вообще-то могу считать, что у тебя все, что было, осталось, правда, кое-что добавилось.
>Что? Всех клиентов обновлять? Щаззз, разбежался! Маздай!!! Эн-тайер рулит форевер!"
Здравствуйте, 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 ответ и заменил его XML ответом. В нем, естественно, никакого <img нет. Мне просто было интересно узнать, как ты HTML парсить собираешься в ответ
Я написал способ парсинга HTML с самого начала. Меня начинает утомлять повторение общеизвестных истин.
PD>Все! Прекрасно! Варианты (SOAP или что-то иное) рассматривать не будем, несущественно это. И ты, и Mamut и WFrag в конце концов пришли к одному и тому же. А поэтому замкну я этот кусочек дерева и сделаю граф.
PD>Вот здесь я суммировал все.
PD>http://www.rsdn.ru/forum/message/2900963.1.aspx
PD>На этот POST запрос придет страница, ты же чуть выше писал, что в сервер в ответ шлет страницу. Из того, что написано ниже, следует, что это XML страница. Так что то, что ты раньше писал
Нет, не следует. Приходит (в общем случае) инвалидная HTML страница, которую мы превращаем в валидный XHTML и потом разбираем.
В реальной жизни у обоих сервисов есть один или несколько 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 в упор не видят. Соответственно, каждый пытается непрерывно расширять и улучшать предоставляемый сервис. С какой интенсивностью они будут это делать — неизвестно, но лучше предполагать, что с большой.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 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? Если так, то это зависит от того, как именно он её выдаёт. Тут, вообще-то, много формулировок для объяснений "как" может быть...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
PD>>Просьба — еще одну итерацию. Только опять полный текст. Не надо формы приводить, несущественно это. Словами опиши. Но полное решение. И подпишись
Вот кстати реальный пример
Здравствуйте, 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 — это высота ? Какое ?
Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ. Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.
PD>Ну или поясни, как ты с помощью Regex или еще чего-то определишь в исходном HTML или в XML, где именно габариты.
ИМХО, ты уже передёргивать начинаешь...
S>>Я написал способ парсинга HTML с самого начала. Меня начинает утомлять повторение общеизвестных истин.
PD>Можно детальнее ? Все же, по каким критериям ты определишь, где именно габариты ?
В точности по тем же самым, по которым они определяются клиентским приложением из твоего варианта решения.
PD>У тебя есть основание утверждать, что 120 — это высота ? Какое ?
Например, вручную проанализировали содержание, потом настроили наши ридеры.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, dmz, Вы писали:
dmz>Если предполагать, что с большой, лучше в явном виде попросить у них API или использовать более вменяемых конкурентов. Но на самом деле, скорость внесения изменений ограничена природой, по этому совсем страшно не бывает. Стабильный массовый сервис не может часто менять API.
Ну вот уж прямо и утрировать слегка нельзя!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, fmiracle, Вы писали:
F>Ну и в целом по теме — главное в веб-приложениях, что они не требуют ничего кроме браузера. А браузеры сейчас распространены повсеместно. Значит, что я купив ноут в магазине сразу же могу использовать Gmail. Мне не нужно ничего скачивать, устанавливать, потом удалять — все же сделано и установлено.
А ссылку на приложение откуда брать будешь? Находить в интернете и тыкать в нее. В случае десктопа точно также будешь тыкать в ссылку с инсталлятором.
F>И придя на работу и откры Gmail я виже его в точности таким же, каким я настроил из дома. И придя к заказчикам, и если вдруг захотелось посмотреть почту — на юбом чужом компьютере я могу это сделать и не замусорить его неинтересными владельцу программами. Это очень, очень удобно. И это определяет успех приложений. Потому что они удобны клиентам.
А чтобы пользоваться корпоративным ящиком будешь запускать клиента или пользоваться веб-мордой почтовика, установленного на работе. Выигрывая в одном, ты теряешь в другом (в универсальности), и это другое объективно важнее.
F>Наша компания пишет корпоративный софт на заказ для относительно крупных российских компаний. Т.е. работающий только внутри компании заказчика. Так вот за последние 4 года было написано, я уж не помню точно, то ли одно, то ли целых два десктоп приложений. Все остальное — веб. Заказчики у нас требуют веб-приложения для работы внутри компании. Именно из-за простоты развертывания и поддержки. Сперва, я помню мы предлагали делать толстые десктоп клиенты, всякие click-one развертывания, сейчас и не предлагаем — не берут, т.к. их полностью устраивает решение с веб-интерфейсом...
Если они экономят на админах, пусть переплачивают за стоимость разработки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
