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? Я честно говоря ничего не понял — что за решение ты предлагаешь?
Здравствуйте, 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.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Да, 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), но на стороне сервера. А именно в нём — открыть много-много фреймов, дабы чуть облегчить проблемы с масштабируемостью, чтобы был не один процесс на каждого клиента а один процесс на десяток-сотню клиентов.
Здравствуйте, 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 делается не совсем одним и тем же способом . На c.com скорее всего, вообще говоря, об операционной системе клиента неизвестно, а если даже и известно, то толку от этого мало — не устроишь же эмуляцию ее возможностей ? Зачем эти проблемы ?
Павел, пардон, а какие именно средства нужны для данной задачи? Где тут проблема? Для чего тебе потребовалась операционка?
PD>Короче — что тут полезного c.com делает ?
Как что делает? Он находит цену доставки заданного товара по заданному адресу. С точки зрения конечного пользователя это — идеальное решение.
Прежде всего потому, что его
а) легко найти
б) легко использовать
в) легко повторно использовать
Теперь мы ждем твоего решения этой задачи — в подробностях, как ты просил, и с подписью. А потом попробуем объяснить, почему твое решение не заработает.
... << 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 может иметь сложную, нетривиальную логику
— все это доступно на бОльшем количестве платформ, чем может себе позволить любое десктоп-приложение
Здравствуйте, 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? Объясни, пожалуйста, что ты имел в виду?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 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>Теперь мы ждем твоего решения этой задачи — в подробностях, как ты просил, и с подписью. А потом попробуем объяснить, почему твое решение не заработает.
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 на пердемет наличия АПИ
Здравствуйте, 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 и не может находиться у меня дома ?
Йоу! Потому что обновить код в одном месте всегда проще и дешевле, чем обновить его в нескольких десятках (сотнях, тысячах...) мест даже при наличии полуавтоматической апдейтилки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
dmz>>Т.е. открывает a.com и b.com в браузере (браузерах), допустим в скрытых фреймах, работает с ними при помощи JS, имитируя действия клиента, потом джаваскриптом-же собирает данные из DOM, потом что-то с ними делает. С браузером этот трюк не выйдет, так как есть защита от XSS, но если сделать своего клиента, который будет использовать несколько инстансов браузера или похаченный браузер — то все будет работать.
PD>Ну ин так. Ты сумел исхитриться с помощью скрытых фрейсов или похаченного браузера. Я бы просто специализированное окно открыл (может, видимое, может нет, может, поток , а не окно)(может, и в процессе браузер, не важно это) и в нем все сделал. Как — детали, несущественно. Но скорее всего — просто шлем a.com запрос в виде некоего XML (к примеру), получаем от него ответ в виде XML и т.д. Пользователь ничего не видит. А результат — может быть, можно и в окне броузера показать, а можно в окне.
Чем это отличается от предложенного нами решения? Наше решение будет работать и на моем Sony Ericsson K750i, а вот дестоп-приложение на нем работать не будет
M>>Кто пришел к HTML? О HTML вообще никто ни разу не упомянул вообще. c.com вытягивает данные с b.com и a.com — где в этой вразе говорится о HTML? Про заполнение веб-форм и парсинг ответа совсем не мы говорили
PD>Да ты же пятью строчками выше. Или я тебя не понял ? Впрочем, это не важно, тема HTML вроде закрыта.
Я там написал — в крайнем случае Но мы уже действительно дугое обсуждаем
Здравствуйте, 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>Вообзе-то парсить их нафиг не надо Их данные есть в Amadeus/Galileo. Если мы пишм действительно большой и серьезный сервис, то заключается договор с одним из них и данные тянутся оттуда
Питнадцать центов транзакция, сами заключайте. А парсер для большинства сайтов пишется и проверяется за час, только на малев пришлось убить два — три дня, и то не моих.
А как допишу эвристику , так вообще будет один парсер на 80% сайтов.
и цена — это не единственная проблема. В общем не надо думать что мы об этом не думали. Мы думали.
PD>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?
HTTP — транспортный протокол. XML — язык разметки. Поэтому то и нет XML протокола поверх TCP/IP. Он вообще НЕ протокол.
Хотя — можно попробовать сделать много-много фреймов в одном браузере... Всё равно криво, но уже на порядок полегше...
