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 тоже не редкость. Мне, в общем-то, как разработчику более-менее все равно -- благо для работы с разными протоколами написано уже много чего, более чем достаточно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Во-во. С WFrag и Mamut мы уже вроде пришли к согласию, что у a.com должен быть XML (или не XML) API, с помощью которого можно запросы делать и ответы получать. Синклер все еще хочет HTML страницу с a.com получать и ее парсить. Подожем немного
Ну, вообще-то, Синклер не только про расковыривание HTML говорил.
В прочем, ладно, подождём.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Хм. Силён Аргумент действительно хороший. Правда, никто не мешает то же самое делать на сервере (хостить закастомизированный браузер) — масштабируемость правда будет ни к чёрту, ну да у нас же крайний случай
Здравствуйте, 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? Про заполнение веб-форм и парсинг ответа совсем не мы говорили
Здравствуйте, dmz, Вы писали:
dmz>Я могу привести решение в виде клиентского приложения. Проблема с сервисами a.com и b.com в том, что если они не рассчитаны на использование роботами, dmz>и имеют сложный интерфейс, а так же какие-то данные рассчитываются джаваскриптом — то единственный способ с ними надежно работать — на клиенте. dmz>Т.е. открывает a.com и b.com в браузере (браузерах), допустим в скрытых фреймах, работает с ними при помощи JS, имитируя действия клиента, потом джаваскриптом-же собирает данные из DOM, потом что-то с ними делает. С браузером этот трюк не выйдет, так как есть защита от XSS, но если сделать своего клиента, который будет использовать несколько инстансов браузера или похаченный браузер — то все будет работать.
Хе-хе. Вот как раз такой случай у меня. Просто вешаем на сервер c.com прокси для AJAX-запросов и всё Ну то есть эта проблема тоже более чем решаема.
Здравствуйте, Left2, Вы писали:
L>Хм. Силён Аргумент действительно хороший. Правда, никто не мешает то же самое делать на сервере (хостить закастомизированный браузер) — масштабируемость правда будет ни к чёрту, ну да у нас же крайний случай
Ха! Да я бы рад захостить, и пробовал. Но. Сколько надо инстансов браузера, что бы все это надежно работало? Как они должны жить? Короче, не живет это под нагрузкой, или это такоой гиморой. Что оказалось проще написать псевдо-интерпретатор джаваскрипта, чем такое делать. Плавали, знаем.
В реальной жизни у обоих сервисов есть один или несколько 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>Я могу привести решение в виде клиентского приложения. Проблема с сервисами 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>Ха! Да я бы рад захостить, и пробовал. Но. Сколько надо инстансов браузера, что бы все это надежно работало? Как они должны жить? Короче, не живет это под нагрузкой, или это такоой гиморой. Что оказалось проще написать псевдо-интерпретатор джаваскрипта, чем такое делать. Плавали, знаем.
Ну и я о том же, да Хотя — можно попробовать сделать много-много фреймов в одном браузере... Всё равно криво, но уже на порядок полегше...
dmz>>Я могу привести решение в виде клиентского приложения. Проблема с сервисами a.com и b.com в том, что если они не рассчитаны на использование роботами, dmz>>и имеют сложный интерфейс, а так же какие-то данные рассчитываются джаваскриптом — то единственный способ с ними надежно работать — на клиенте.
PD>Уф! Наконец-то! Именно к этому я и веду.
Это редкий, клинический случай. Более того, эта проблема решается по другому. Она решается административно. Мы или даем денег владельцам a.com что бы они
нам предоставили вменяемый интерфейс. Или взять с них денег и предоставить им вменяемый интерфейс, если они его сами делать не могут. Или дать денег тому, кто уже это сделал — ну, типа, Амадеусу. А вот когда нет денег или ресурсов — тогда и начинаются пляски; более того, использования клиента проблему не решит, а только усугубит.
Это я как практик говорю.
PD>Ну ин так. Ты сумел исхитриться с помощью скрытых фрейсов или похаченного браузера. Я бы просто специализированное окно открыл (может, видимое, может нет, может, поток , а не окно)(может, и в процессе браузер, не важно это) и в нем все сделал. Как — детали, несущественно. Но скорее всего — просто шлем a.com запрос в виде некоего XML (к примеру), получаем от него ответ в виде XML и т.д. Пользователь ничего не видит. А результат — может быть, можно и в окне броузера показать, а можно в окне.
Какого XML если a.com не имеет вменяемого интерфейса по условию? Если он принимает XML и отдает XML — то обозначенная мной проблема отсутствует, задача сама собой решилась.
