ГВ>>>Про HTTP вспомнили, потому что разговор заведён про web-приложения. Что ж тут удивительного? Вспоминали и про бинарные форматы.
PD>>Нет, мой вопрос не в этом. Зачем он тут нужен ? Без него можно вообще обойтись ?
ГВ>Ответ ниже.
Я что-то не нашел.
ГВ>>>c.com выполняет две очень важную функцию: изолирует нашего пользователя от вывертов a.com и b.com.
PD>>Заменяя при этом на необходимость знать выверты самого c.com. Он что, их лучше, умнее. что ли ?
ГВ>Ask?! У серверов a.com и b.com есть фатальный недостаток — они написаны не нами. Поэтому наш сервер быстрее, сильнее и превосходит их во всём. Вон, ни тот, ни другой не знают даже о существовании друг друга. Ламерьё!
Действительно. Помню, 5 лет назад разговаривал с разработчиком a.com. Он мне про x.com и y.com в точности те же аргументы приводил
PD>>Да, будут два микроклиента. Но для пользователя — один из них. Пока он не работает одновременно с Windows и Linux. А еще проще — он знает, что ему надо установить клиента. Для установки клиента надо из броузера зайти по такому-то URL, там либо спросят об ОС, либо автоматически ее определят, выдадут клиента и он установится. И что ?
ГВ>Вестимо, начнёт работать. Суть не в этом. Вопрос в том, как часто его придётся обновлять.
Не придется. Он сам обновится. Поставь себе Mozilla или FireFox и жди. Как только новая версия появится, предложат обновить. И Windows Update так же работает, только не всю ОС (слава богу . а лишь кое-что заменяет. И я даже не знаю, что именно.
ГВ>Йоу! Потому что обновить код в одном месте всегда проще и дешевле, чем обновить его в нескольких десятках (сотнях, тысячах...) мест даже при наличии полуавтоматической апдейтилки.
А в чем, собственно, проще ?
Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д. При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.
M>>Можно тогда вообще все протоколы общения выкинуть в топку, ведь все можно поверх TCP/IP делать. Открывать сокет, писать данные напрямую
PD>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т.д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
...
Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
Стартовая строка (англ. Starting line) — определяет тип сообщения;
Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения; Тело сообщения (англ. Message Body) — непосредственно данные сообщения.
POST
Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса.
PD>>>4. На клиенте доступны все средства, предоставляемые операционной системой клиента. Например, можно реагировать на нажатия некоторой клавиши, что в Windows и Linux делается не совсем одним и тем же способом .
M>>Ключевой момент. Для веб приложения это нажатие будет обрабатываться абсолютно одинаковым способом и на Линуксе и на Винде, и на Symbian и на Android'е
PD>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?
Какой low-level keyboard hook с помощью SetWindowsHookEx?????
onKeyPress в Яаскрипте уже отменили?
Работу с клавиатурой в Флэше уже отменили?
PD>>>На c.com скорее всего, вообще говоря, об операционной системе клиента неизвестно, а если даже и известно, то толку от этого мало — не устроишь же эмуляцию ее возможностей ? Зачем эти проблемы ?
M>>Зачем c.com'у знать об операционной системе клиента?
PD>Так ведь на c.com фактически все приложение-то и оказалось. На клиенте только ввод да картинка. Как только что-то усложнится — понадобится знать, можно ли это вообще клиенту вернуть или у него получить.
????????????????????????????7
О каком клиенте мы говорим?
Еще раз. Веб-приложение — это сраница плюс сервер. Одно изменяется соответственно другому. С какого перепугу вдруг на странице появятся новые формы ля введения данных, если на сервере для них не будет логики, их обрабатывающей?
M>>Действительно, зачем нужен сайт типа Expedia? Ведь можно убить n-цать человеколет, чтобы сделать десктоп-приложение, работающее на всех операционных системах в мире, причем обладающее далеко нетривиальной логикой
PD>Не аргумент, извини
Еще как аргумент. Сколько времени и денег потребуется, чтобы разработать десктоп приложение, работающее на:
Windows 2000
Windows XP
Windows Vista
Windows Mobile 5
Windows Mobile 6
всех дистрибутивах Линукса
MacOS X
MacOS X for iPhone
Symbian
Andorid
Qtopia
OpenMoko
и т.п.
А билет на expedia я смогу заказать и используя свой SE K750i + Opera Mini
M>>c.com нужен по следующим причинам: M>>- унифицированый доступ к разрозненым сервисам M>>- в случае если эти сервисы изменятся, изменится интрфейс их взаимодействия, условия взаимодействия, адреса взаимодействия и т.п., то пользователь услугами c.com'а от этого полностью защищен M>>- c.com может иметь сложную, нетривиальную логику M>>- все это доступно на бОльшем количестве платформ, чем может себе позволить любое десктоп-приложение
PD>Все замечательно, и все же — почему для этого c.com должен стоять в Калифорнии, а не у меня в квартире ?
О, в квартире можно поставить сервер, хранящий информацию терабайтами? 0_о
Здравствуйте, dmz, Вы писали:
M>>Вообзе-то парсить их нафиг не надо Их данные есть в Amadeus/Galileo. Если мы пишм действительно большой и серьезный сервис, то заключается договор с одним из них и данные тянутся оттуда
dmz>Питнадцать центов транзакция, сами заключайте. А парсер для большинства сайтов пишется и проверяется за час, только на малев пришлось убить два — три дня, и то не моих. dmz>А как допишу эвристику , так вообще будет один парсер на 80% сайтов.
dmz>и цена — это не единственная проблема. В общем не надо думать что мы об этом не думали. Мы думали.
Не спорю Вон, kayak.com за счет этого и живет, судя по всему, и ничего, довольно популярен
Здравствуйте, Fox007, Вы писали:
PD>>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?
F>HTTP — транспортный протокол.
Первый раз такое слыщу. Я как-то считал, что транспортным является TCP, а HTTP — протокол уровня приложения.
>XML — язык разметки. Поэтому то и нет XML протокола поверх TCP/IP. Он вообще НЕ протокол.
Он — не протокол, верно. Но что мешало сделать его протоколом на том же уровне, что и HTTP, FTP, SMTP... ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И все же — почему код, позволяющий оперативно модифицировать логику обработки данных, приходящих с a.com и b.com, должен находиться на некоем физическом сервере c.com и не может находиться у меня дома ?
Знаешь, а если с CORBA помудрить, то можно и на клиентскую машину затащить... Уж гулять, так гулять!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не придется. Он сам обновится. Поставь себе Mozilla или FireFox и жди. Как только новая версия появится, предложат обновить. И Windows Update так же работает, только не всю ОС (слава богу . а лишь кое-что заменяет. И я даже не знаю, что именно.
Серьезно? А у меня не обновляется, вот незадача. Более того, у меня прав-то даже нет его обновить! А запускается он, естественно, с моими правами.
PD>А в чем, собственно, проще ?
См. выше пример про FF. А вот http://google.com «у меня» постоянно обновляется — никаких проблем Вон suggest не так давно появился.
PD>Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д.
Кому должен?
PD>При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Он — не протокол, верно. Но что мешало сделать его протоколом на том же уровне, что и HTTP, FTP, SMTP... ?
Что такое стек протоколов ясно? Понятно, зачем собирают стеки протоколов, а не начинают каждый протокол с описания сигналов в проводе и физических характеристик среды передачи данных?
Здравствуйте, Sinclair, Вы писали:
PD>>[/code] S>var heightExpression = new Regex(@"(?<=Vertical Size\D+)\d+");
PD>>А если сайт выдает страницу не на английском ? Как там по португальски "высота" ? S>Павел, ты вправду тупишь, или просто меня пораздражать решил? Я тебе уже написал все-все комментарии про то, как я буду решать задачу в тысяче разных случаев.
Извини, но ты что-то дурочку валяешь. При чем тут замена Height на Vertical Size ? На каком основании ты решил, что употребление где-то в странице Vertical Size или Height дает тебе право ожидать, что дальше размер ? Кто тебе обещал, что завтра Height они на Vertical Size не поменяют ?
S>Если сайт португальский — я напишу португальский регексп. К чему этот идиотизм весь?
Вот именно. Парсим неизвестно что и утверждаем, что так можно надежные данные получить
>Вон я присылал тебе ссылку на реальную задачу — парни берут курс валюты с rbc.ru. Именно разбором HTML. Поэтому перестань страдать херней и проверять мои знания регекспов.
Нужны мне твои знания регэкспов как рыбке зонтик. Ты никак не можешь понять, что я тебе про то, что у тебя нет способа это вообще корректно определить, а ты мне строку в регэкспе меняешь!
>Вот давай ты напишешь, как ты будешь парсить такой респонс в твоем клиенте.
Я где-то обещал, что буду парсить HTML ? Ссылочку, пожалуйста!
>>>Из прочтения инструкции по пользованию приложением a.com, которая там рядом неизбежно расположена, PD>>У сайтов всегда есть инструкции по их пользованию ? Что-то я не припомню на сайтах таких инструкций — хорошо еще , если карту сайта приведут. Мы ведь о парсинге HTML говорим вроде, так, не о XML-RPC или SOAP. Вот там, да, инструкция будет. S>Павел, я позволю себе напомнить, что вымышленный тобой сервис a.com предназначен для людей. Это означает, что среднестатистический пользователь этого сервиса способен понять, где именно на странице расположен размер, и в чем он измеряется. Из инструкции и других источников. Я отличаюсь от среднестатистического пользователя тем, что умею делать view source и смотреть, откуда взялась эта цифра, и как ее выдрать из остальной разметки.
Так, похоже, говорить больше не о чем. Все ясно. Ты базируешь свой метод на анализе существующей страницы и применяешь малоубедительные эвристики для такого нахождения данных, и не задумываешься, что все это полетит к чертовой матери, если дизайнер сайта решит там слово поменять. Обсуждать такое решение я не намерен.
>>>а также из других источников PD>>И какие же другие источники у тебя есть , когда ты получил эту страницу и ничего больше ? S>Павел, ты вообще хоть раз в интернете был?
Нет. В первый раз вот здесь. Если ты решил дурочку валять — поищи другого оппонента, а я вынужден дискуссию с тобой прекратить.
Здравствуйте, WFrag, Вы писали:
WF>Что такое стек протоколов ясно? Понятно, зачем собирают стеки протоколов, а не начинают каждый протокол с описания сигналов в проводе и физических характеристик среды передачи данных?
Ну это уж совсем несерьезно. При чем тут весь стек ? Кто предлагал реализовать XML протокол на базе физического уровня ? HTTP на вершине стека, под ним TCP, а что ниже — сейчас тут ни при чем. Почему XML не может быть поверх TCP, зачем нужен HTTP в качестве промежуточного слоя ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так, похоже, говорить больше не о чем. Все ясно. Ты базируешь свой метод на анализе существующей страницы и применяешь малоубедительные эвристики для такого нахождения данных, и не задумываешься, что все это полетит к чертовой матери, если дизайнер сайта решит там слово поменять. Обсуждать такое решение я не намерен.
В этом твое отличие от оппонентов. У тебя мышление не инженерное.
Здравствуйте, WFrag, Вы писали:
WF>Серьезно? А у меня не обновляется, вот незадача. Более того, у меня прав-то даже нет его обновить! А запускается он, естественно, с моими правами.
Ну и что ? Это аргумент в теоретическом споре ?
PD>>Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д.
WF>Кому должен?
Не кому должен, а должен. Точно так же, как сайт a.com со своими страницами должен отвечать по протоколу HTTP, а не черт знает что. Вот и сервис должен поддерживать свой АПИ.
PD>>При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.
WF>Правда? Ты гарантируешь?
Microsoft гарантирует одно из 3
Либо Win16 (или DOS) приложение будет работать
Либо оно (или ОС) выдаст корректную диагностику, почему оно не может работать.
PD>Решение с клиентом
PD>Клиент выдает на экран форму, в которой запрашивается название продукта и адрес получателя. Эта форма не получена ни с a.com, ни c b.com, а просто принадлежит клиентному приложению. После нажатия Submit клиентное приложение берет название и отправляет серверу a.com. Получив ответ от него, оно берет полученные данные, добавляет к ним адрес получателя и шлет серверу b.com. Полученный от него ответ возвращается пользователю.
А мне вот очень интересны технические подробности. А то решение тут описано на уровне ученика 9-го класса — "я сделаю програмку, в одном окошке пользователь введёт данные а в другом получит результат". Нельзя ли чуть подробнее — по каким протоколам будешь ходить к серверам и что будешь делать если эти протоколы поменяются (сайты нам не принадлежат, помнишь?), как будешь осуществлять авто-апдейт программы, как сделаешь её кросплатформенной. Хотя бы ключевые слова хотелось бы услышать. А то на данный момент мне сдаётся что ты здесь куче народу морочишь голову, заставляя подписываться под какими-то утверждениями и угрожая тузом в рукаве который ты вот-вот вытащишь и все поймут что веб-приложения — фуфло.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну это уж совсем несерьезно. При чем тут весь стек ? Кто предлагал реализовать XML протокол на базе физического уровня ? HTTP на вершине стека, под ним TCP, а что ниже — сейчас тут ни при чем.
Кто сказал, что HTTP на вершине? Пойми, есть твои теоретические знания, а есть суровая реальность. Так вот, в реальности нет никакой 7-и уровневной модели OSI ISO, нет никакого HTTP на вершине стека.
Тебя, возможно, это шокирует, но HTTP протокол можно использовать, например, для туннелирования TCP/IP. Предлагаю подумать, как это трактуется с точки зрения 7-и уровневой модели. И такое встречается сплошь и рядом.
PD>Почему XML не может быть поверх TCP, зачем нужен HTTP в качестве промежуточного слоя ?
Вот именно потому же, почему мы не базируем его на физическом уровне. Потому что HTTP это очень удобная подложка для более высокоуровневых протоколов. Как уже заметили, сжатие, кэширование, шифрование, аутентикация.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и что ? Это аргумент в теоретическом споре ?
Программирование — это инженерия в первую очередь. Поэтому требую спор именовать инженерным. Приведенный аргумент в инжинерном споре более чем применим — я пользователь разных систем.
WF>>Кому должен?
PD>Не кому должен, а должен. Точно так же, как сайт a.com со своими страницами должен отвечать по протоколу HTTP, а не черт знает что. Вот и сервис должен поддерживать свой АПИ.
А вот ничего он не должен. Он и по HTTP не должен отвечать, просто он тогда нафиг никому не нужен будет. Он по HTTP отвечает не потому, что это правильно, а потому что другого выбора нет А вот менять свой API он может.
PD>Microsoft гарантирует одно из 3
PD>Либо Win16 (или DOS) приложение будет работать PD>Либо оно (или ОС) выдаст корректную диагностику, почему оно не может работать.
PD>Вариант "deprecated" не реализован.
PD>Если знаешь иное — приведи.
А причем тут Microsoft? a.com написан не Microsoft, а какой-то конторой. Если она не будет заинтересована в таких гарантиях, то и давать их не будет. Зачем им это?
S>>Если сайт португальский — я напишу португальский регексп. К чему этот идиотизм весь?
PD>Вот именно. Парсим неизвестно что и утверждаем, что так можно надежные данные получить
Парсим мы известно что. Ответ на один и тот же запрос с северу более-менее стабилен. Можно написать монитор, который будет проверять,
что формат выдачи не менялся. Можно сделать интеллектуальный анализатор.
Точно так же, хозяева сервиса могут поменять формат XML. И что? О чем мы вообще говорим? Если по условию задачи a.com уже есть, и нормального API у него нет — то пользуемся чем есть. Если владельца a.com предоставили явное API — то они берут на себя обязательства его поддерживать. По большому счету, все равно, что возвращает из API — HTML, CSV, YAML, Plain Text, XML такой или сякой — главное что бы формат не менялся по десять раз на дню.
Какая-то сплошная демагогия. Альтернатива-то в чем? Придумать Единый Формат Описания Любых Данных и всех заставить им пользоваться?
Если что-то нельзя сделать автоматически на сервере — то это нельзя сделать автоматически и на клиенте. И клиент и сервер — программа. Какая разница где она работает?
Рисует вам интерфейс при помощи Win32 API или при помощи HTML в браузере?
PD>Так, похоже, говорить больше не о чем. Все ясно. Ты базируешь свой метод на анализе существующей страницы и применяешь малоубедительные эвристики для такого нахождения данных, и не задумываешься, что все это полетит к чертовой матери, если дизайнер сайта решит там слово поменять. Обсуждать такое решение я не намерен.
Это летит к чертовой матери, если нет эвристики, а есть тупой граббинг, да еще повязанный на дизайн. Если есть эвристика и обратная связь — то сделать так, что бы все улетело к чертовой матери довольно трудно, надо много стараться. Пример — есть сайт, возвращающий размеры животных. Есть у нас запрос и мы знаем, что сервис возвращает тип животного и размеры. Варьируем данные запроса, смотрим изменения результата, после преобразования HTML в нормальную форму. После этого можно сделать очень вероятный вывод о том, где какие данные находятся и как выглядят. К этому всему мы привязываем скоринг и монитор входных и выходных данных — и если результаты отличаются от того, что мы ожидаем, в нашей конторе звучит аларм, мигают красные лампы — наши программисты бросаются к компам и за десять минут фиксят парсер.
PD>Нет. В первый раз вот здесь. Если ты решил дурочку валять — поищи другого оппонента, а я вынужден дискуссию с тобой прекратить.
Это недальновидно, потому что Синклер говорит по-существу, и его слова продиктованы практическим опытом, что заметно всем, кто в теме.
А вот что вы пытаетесь доказать, пока непонятно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, 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.
PD>Не пойдет. Я не о существующей реализации, а о принципах построения говорю. Это все можно было без HTTP сделать или нет ?
Конечно можно. PD> То, что это наработано, а поэтому легко употребить — не спорю. Но ведь мы идеологию обсуждаем, так ? Для идеологии наличие существующих возможностей не аргумент.
Ок, давайте тогда изобретем другой протокол поверх TCP/IP. Сделаем его stateless, для обеспечения масшитабируемости. Это идеологически важно.
Внедрим в него поддержку
— аутентификации
— кэщирования
— компрессии
— безопасности коммуникации
— перенаправления на другие источники
— обработки ошибок
— получения частичных результатов
— отправки запросов только в случае выполнения предусловий
И получим еще один HTTP.
PD>Ну-ну, поехали. Трояна можно и без EXE подцепить, а при закачке новых EXE от Mozilla или (о ужас) Windows Update, который заменяет модули ОС, я что-то не боюсь этого. Нечего брать клиентов с подозрительных сайтов да и вообще туда ходить.
PD>Я имел в виду, что клиенту надо отдать эти сотни Кб с a.com и b.com
Непонятно. Павел, ты поставил задачу — я ее решил. Просто поверь на слово, что если ты поставишь другую задачу — я ее тоже решу. Но давай не будем оценивать пригодность решения одной задачи для решения другой, ок?
PD>Для данной — может, и нет. Но в общем случае — нужны.
В общем случае решение может быть и другим.
PD>>>Короче — что тут полезного c.com делает ? S>>Как что делает? Он находит цену доставки заданного товара по заданному адресу. С точки зрения конечного пользователя это — идеальное решение. S>>Прежде всего потому, что его S>>а) легко найти PD>Ну никак не легче, чем клиента, делающего то же самое.
Ок, предположим, что одинаково. S>>б) легко использовать PD>То же самое.
НЕТ!!! Вот я нашел через гугл cтраничку c.com. В моем варианте я кликаю по ссылке — и через полсекунды передо мной "клиент", который я могу тут же попробовать.
В твоем варианте я кликаю по ссылке — и вижу диалог "скачать/запустить". Потом, через некоторое время (а ты в 400 байт своего умного клиента не уложишь), я получу инсталлятор на к себе машину. Теперь мне надо будет согласиться его установить. Для чего, как минимум, нужны административные права. Допустим, я его всё же рискнул и сумел поставить. Теперь сам по себе никуда не исчезнет, а продолжит отжирать место у меня на винте и в start menu. В то время как 400 байт исчезнут из кэша по стандартному LRU алгоритму, и мне нет нужды следить за сносом всякого мусора.
Для 98% пользователей вот эти "маленькие трудности" приведут к тому, что они нажмут back в браузере и поищут более дружелюбный сервис, реализованный в более прямой архитектуре.
S>>в) легко повторно использовать PD>Абсолютно. Установив раз, больше никогда устанавливать не придется — пока новая версия не появится. Но и при появлении новой версии не обязательно. А появится новая версия — он устроит auto upgrade. Как FireFox делает , к примеру.
Отлично. Теперь ты начинаешь усложнять жизнь разработчику. В игру вступает сервер апдейтов и новая функциональность клиента, которую кто-то должен написать. Для веб приложений auto-update доступен бесплатно, из-за особенностей архитектуры.
Но я-то имел в виду, что пользователь может просто добавить в favorites (или на десктоп, или куда угодно) закладку, которая приведет его сразу к ответу на вопрос "сколько стоит привезти слона в Омск", даже если цены изменились. А может сохранить конкретный результат через Save As или через copy/paste для будущего сравнения.
S>>Теперь мы ждем твоего решения этой задачи — в подробностях, как ты просил, и с подписью. А потом попробуем объяснить, почему твое решение не заработает.
PD>Хм, так я же его с самого начала привел. PD>http://www.rsdn.ru/forum/message/2899518.1.aspx
Нет, ты тут из меня все соки выжал, до подробных инструкций про то, как парсить семь разных видов результатов.
Будь любезен, опиши в деталях
— как именно твой клиент отправляет запрос на a.com
— как именно он получает ответ, как узнает, где в нем данные, а где мусор
— как он отправляет запрос на b.com
— как он получает от него данные
— что он делает, если обнаруживает, что сервис b.com не отвечает
— как он определяет наличие более новой версии себя же
— как и откуда он получает эту новую версию
— как он выполняет замену на лету кода, исполняющегося прямо сейчас
— сколько примерно времени займет разработка такого клиента, который бы успешно работал на windows
— сколько примерно времени займет разработка такого клиента, который бы cмог работать на мобильных платформах
— сколько примерно времени займет разработка такого клиента, который бы cмог работать на linux
— сколько примерно времени займет разработка такого клиента, который бы cмог работать на freebsd
На всякий случай я приведу пессимистичную оценку стоимости реализации своего клиента: 5 рабочих дней.
Из них 1 — на анализ a.com и b.com, 1 на выполнение собственно сервиса, 3 на украшение UI.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну это уж совсем несерьезно. При чем тут весь стек ? Кто предлагал реализовать XML протокол на базе физического уровня ? HTTP на вершине стека, под ним TCP, а что ниже — сейчас тут ни при чем. Почему XML не может быть поверх TCP, зачем нужен HTTP в качестве промежуточного слоя ?
Потому, что XML — это не протокол. Это формат. С тем же успехом можно спрашивать "почему нельзя использовать UTF-8 вместо SMTP".
Поясняю на пальцах: протокол — это спецификация диалога.
Он описывает состояния диалога, сообщения между клиентом и сервером, уместные в каждом состоянии, а также правила перехода из состояния в состояние. Компрене ву?
XML ничего близкого не содержит. Он может использоваться в качестве формата сообщений того или иного прикладного протокола, построенного поверх TCP/IP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>В противном случае надо трогать за вымя oneworld на пердемет наличия АПИ
dmz>За ссылку спасибо — посмотрел, потестил, посмеялся.
Они кстати предлагают именно вариант павла — скачать какой-то клиент на очень ограниченное количество платформ. И пользоваться все равно удобнее expedia/kayak/веб-интерфейсом соответствующих компаний
