M>Они кстати предлагают именно вариант павла — скачать какой-то клиент на очень ограниченное количество платформ. И пользоваться все равно удобнее expedia/kayak/веб-интерфейсом соответствующих компаний
Ой. Нет, до этого не дошло, я просто поискал полеты из домодедово в берлин-тигель, посмеялся над результатом и ушел.
Здравствуйте, Mamut, Вы писали:
PD>>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?
M>?????????????????????????
M>Где это XML разделяется знаком & ???????????
Слушай, что с тобой ? Ты меня совсем понимать перестал. Я говорю, что XML передается сейчас с помощью HTTP, а для запроса нужна командная строка с этими &.
Вот такое можешь себе представить ?
Появился XML протокол. Порт YYY
При обращении к серверу a.com, поддерживающему XML протокол, надо ему передать некий "приветственный" XML. По порту YYY.
В ответ он , если жив, пришлет XML-ответ (аналог 200 OK)
После этого ему шлется произвольный XML на порт YYY. С запросом. Там не надо никаких страниц указывать. Там запрос на АПИ, который сервер a.com опубликовал. (Для получения этого АПИ надо ему послать XML запрос с единственной командой — дай АПИ)
Он его анализирует и определяет, что за запрос.
Формирует ответ, если может. Если не может, формирует ответ "ошибка". Ответ в XML — в любом случае.
Ответ посылается клиенту, он его принимает и анализирует. XPath, DOM и т.д.
Ответ используется клиентом как ему надо.
Где тут командная строка ? Где тут адрес страницы ? Где вообще страницы ? Где HTML ? (хотя. конечно, может быть, на некий запрос придет ответ в виде XML с CDATA, содержащем HTML). Где тут место HTTP ?
M>Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента.
Где в моей модели URI ? Кроме имени хоста, ничего не надо.
>Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т.д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
И на здоровье. Если надо в ответ прислать просто текст на китайском — шлите. Картинку в jpg — шлите. HTML — шлите. Но в ответе в виде элемента XML ответа.
M>Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
<skipped>
Спасибо за объяснения. См выше.
PD>>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?
M>Какой low-level keyboard hook с помощью SetWindowsHookEx?????
Обыкновенный. Твое web-приложение — это игра, динамическая. В Windows, допустим, можно поставить этот хук на клавиатуру, если надо.
M>onKeyPress в Яаскрипте уже отменили?
Батенька, ну не надо так. Фокус с приложения уйдет — ничего не получишь. А я хочу. чтобы мое приложение реагировало на нажатия клавиш, даже если оно не в фокусе.
M>Работу с клавиатурой в Флэше уже отменили?
Флэш — это ActiveX . Исполняемый код, с вашего позволения. Встроившийся в IE, верно, но все же это EXE (DLL).
PD>>Так ведь на c.com фактически все приложение-то и оказалось. На клиенте только ввод да картинка. Как только что-то усложнится — понадобится знать, можно ли это вообще клиенту вернуть или у него получить.
M>????????????????????????????7
M>О каком клиенте мы говорим?
О web-клиенте. О том, что на нем игра сетевая, к примеру, а работать приходится через c.com.
M>Еще раз. Веб-приложение — это сраница плюс сервер. Одно изменяется соответственно другому. С какого перепугу вдруг на странице появятся новые формы ля введения данных, если на сервере для них не будет логики, их обрабатывающей?
А просто на том основании, что в моем понимании веб-приложение должно быть просто приложением, имеющим доступ к внешним источникам. И как в любом просто приложении в нем могут происходить самые разные действия, в частности, приводящие к изменению внешнего вида. А сервер мне тут нужен только как источник данных
M>Еще как аргумент. Сколько времени и денег потребуется, чтобы разработать десктоп приложение, работающее на: M>Windows 2000 M>Windows XP M>Windows Vista M>Windows Mobile 5 M>Windows Mobile 6
M>всех дистрибутивах Линукса
M>MacOS X M>MacOS X for iPhone
M>Symbian
M>Andorid
M>Qtopia M>OpenMoko
M>и т.п.
Да разработаны же они! Та же Mozilla, к примеру. Денег — да. Времени — да. Но мы, кажется, вопрос все же про архитектуру и идеологию начали, нет ? Я и не утверждаю, что мое решение реально можно завтра пустить в ход. Все аргументы насчет денег и средств принимаю. Насчет сроков тоже.
Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.
M>О, в квартире можно поставить сервер, хранящий информацию терабайтами? 0_о
Ну не смеши ради бога. Что это такле на c.com в его нынешней версии есть, что требует терабайтов ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Приятно с тобой беседовать. Я серьезно
ГВ>>>>Про HTTP вспомнили, потому что разговор заведён про web-приложения. Что ж тут удивительного? Вспоминали и про бинарные форматы. PD>>>Нет, мой вопрос не в этом. Зачем он тут нужен ? Без него можно вообще обойтись ? ГВ>>Ответ ниже. PD>Я что-то не нашел.
Главная часть ответа — это сопоставление количества потребных транзакций обновления.
ГВ>>>>c.com выполняет две очень важную функцию: изолирует нашего пользователя от вывертов a.com и b.com. PD>>>Заменяя при этом на необходимость знать выверты самого c.com. Он что, их лучше, умнее. что ли ? ГВ>>Ask?! У серверов a.com и b.com есть фатальный недостаток — они написаны не нами. Поэтому наш сервер быстрее, сильнее и превосходит их во всём. Вон, ни тот, ни другой не знают даже о существовании друг друга. Ламерьё! PD>Действительно. Помню, 5 лет назад разговаривал с разработчиком a.com. Он мне про x.com и y.com в точности те же аргументы приводил
И правильно делал. x.com и y.com — это вообще древний хлам, про них в приличном обществе говорить уже не принято.
PD>>>Да, будут два микроклиента. Но для пользователя — один из них. Пока он не работает одновременно с Windows и Linux. А еще проще — он знает, что ему надо установить клиента. Для установки клиента надо из броузера зайти по такому-то URL, там либо спросят об ОС, либо автоматически ее определят, выдадут клиента и он установится. И что ? ГВ>>Вестимо, начнёт работать. Суть не в этом. Вопрос в том, как часто его придётся обновлять. PD>Не придется. Он сам обновится.
Сам... Как же! Юзер нажмёт на кнопку, и ещё раз, и ещё...
ГВ>>Йоу! Потому что обновить код в одном месте всегда проще и дешевле, чем обновить его в нескольких десятках (сотнях, тысячах...) мест даже при наличии полуавтоматической апдейтилки. PD>А в чем, собственно, проще ?
В штуках транзакций обновления. В случае сервера такая транзакция одна. Меньше просто не придумаешь. И никаких возмущённых пользователей, которые не тем местом не туда нажали при получении критического обновления. А здесь, обрати внимание, ещё и особо пикантная ситуация: устроить нам весёлую жизнь с пользователями может руководство компаний, ответственных за a.com или b.com. За примерами таких ситуаций далеко ходить не надо. Когда там отгремела война ICQ и MSN? Тоже вот, оба юзали протоколы друг друга, одновременно модифицируя свои собственные, чтобы другой не смог.
PD>Хинт — у сайтов a.com и b.com (они же сервисы, они же по XML общаются с нами) должен быть опубликованный API. Этот АПИ должен развиваться примерно по тем же принципам, по которым развивается .Net API, Java API и т.д.
Ну... Я так не играю. То у них ничего нет, то вдруг какой-то весьма хорошо поддерживаемый API появился. API — это как никак, Application programming interface. Если действительно API есть, то, между прочим, вариант с многочисленными браузерами в клиенте превращается в чистую фантастику. То есть получается, что ты клонил собеседников к тому, что сам же и опровергаешь путём дополнительных уточнений.
PD>При появлении новых средств старые либо продолжают поддерживаться, либо возвращают "deprecated", но все же работают, либо (очень редко) возвращают "obsolete" (вроде SetSelectorLimit из Win16). Так что старый клиент работать будет. Как до сих пор работают Win16 приложения, хотя они никому не нужны. И новый будет.
Это очень существенное дополнительное условие. Спору нет, если у нас есть гарантия, что API a.com и b.com стабильны как скала, то может быть, можно и не заморачиваться с запуском своего узла только ради того, чтобы сопоставить продукт и цену доставки. Ну а если нет? Потому и предлагается решение, которое заведомо проще сопровождать, чем вагон клиентских приложений.
И кроме всего прочего, даже если API серверов стабилен, нельзя снять аргумент, касающийся того, что даже нашу собственную, то бишь, разработанную нами функциональность проще апгрейдить и фиксить на одном только сервере, а не уговаривая клиентов загрузить себе очередной апдейт.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Извини, но ты что-то дурочку валяешь. При чем тут замена Height на Vertical Size ? На каком основании ты решил, что употребление где-то в странице Vertical Size или Height дает тебе право ожидать, что дальше размер ? Кто тебе обещал, что завтра Height они на Vertical Size не поменяют ?
Мне — никто. И тебе — никто. Дальше что?
Я отдаю себе отчет в ненадежности такого решения — но я с самого начала написал, что это крайний случай.
Когда они поменяют Height на Vertical Size, я получу нотификацию от своего единственного экземпляра сервиса c.com о том, что надо пойти и проверить, что у них там выдается.
Через максимум один день я поменяю регексп и всё заработает. А что будешь делать ты? Это же была твоя идея — делать всё тайком от сервисов a.com и b.com.
К счастью, в реальной жизни такие решения успешно работают. Именно благодаря тому, что приложения типа a.com и b.com писал не ты, а вменяемые разработчики. И они не стали выбирать "XML поверх TCP", который бы я никогда не распарсил.
>>Вон я присылал тебе ссылку на реальную задачу — парни берут курс валюты с rbc.ru. Именно разбором HTML. Поэтому перестань страдать херней и проверять мои знания регекспов.
PD>Нужны мне твои знания регэкспов как рыбке зонтик. Ты никак не можешь понять, что я тебе про то, что у тебя нет способа это вообще корректно определить,
А у тебя такой способ есть? Откуда?
PD>Так, похоже, говорить больше не о чем. Все ясно. Ты базируешь свой метод на анализе существующей страницы и применяешь малоубедительные эвристики для такого нахождения данных, и не задумываешься, что все это полетит к чертовой матери, если дизайнер сайта решит там слово поменять. Обсуждать такое решение я не намерен.
Ок, предложи другое решение. Павел, сферические задачи в вакууме не существуют.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, что с тобой ? Ты меня совсем понимать перестал. Я говорю, что XML передается сейчас с помощью HTTP, а для запроса нужна командная строка с этими &.
Не нужна. Никаких командных строк в HTTP нет даже приблизительно. Пары ключ=значение, разделенные & — это тоже не обязательный элемент HTTP а всего лишь один из форматов данных.
PD>Вот такое можешь себе представить ?
PD>Появился XML протокол. Порт YYY
[описание скипнуто]
Это не XML протокол. Это протокол ZZZ, использующий XML в качестве формата данных. SOAP, например.
PD>Где в моей модели URI ? Кроме имени хоста, ничего не надо.
Аналог URI в Вашей модели будет где-то внутри "произвольного XML с запросом". Поскольку, как ни крути, а сервису нужно сообщить, какое действие он должен выполнить или какой ресурс вернуть — а именно для этого в HTTP нужен URI.
PD>И на здоровье. Если надо в ответ прислать просто текст на китайском — шлите. Картинку в jpg — шлите. HTML — шлите. Но в ответе в виде элемента XML ответа.
И чем "элемент XML ответа" лучше, чем тело HTTP-ответа? То же самое, вид в профиль — это если даже закрыть глаза на то, что XML никак не подходит для двоичных данных, и чтобы впихнуть туда картинку, придется заниматься извращениями и раздувать пересылаемые данные в полтора-два раза.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так, похоже, говорить больше не о чем. Все ясно. Ты базируешь свой метод на анализе существующей страницы и применяешь малоубедительные эвристики для такого нахождения данных, и не задумываешься, что все это полетит к чертовой матери, если дизайнер сайта решит там слово поменять. Обсуждать такое решение я не намерен.
Так где все-таки подробное описание соответствующего клиентского приложения? С описанием методов получения и интерпретации данных с a.com и b.com?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так, похоже, говорить больше не о чем. Все ясно. Ты базируешь свой метод на анализе существующей страницы и применяешь малоубедительные эвристики для такого нахождения данных, и не задумываешься, что все это полетит к чертовой матери, если дизайнер сайта решит там слово поменять. Обсуждать такое решение я не намерен.
Э... А это не твой ли десктоп собирался вынимать данные из того же a.com? Ты уж как-то определись сам: стабильный API у этих серверов или нет. А то говоришь, что он не стабильный — плохо; говоришь, что стабильный — тоже плохо. На худой конец, чётче сформулируй граничные условия, что ли...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?
Ну если мы начали вдаряться в абстрактную философию, не обращая внимание на окружающую действительность, то давай поймем — зачем нам TCP/IP и XML? Почему не придумать какой-нибудь другой протокол и не гонять по нему данные в формате, скажем, ASN.43? Чем таким хорош TCP/IP?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?
Игра, которой надо получать информацию о товарах и стоимость почтовых отправлений? Странные у Вас развлечения, честное слово.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
PD>Появился XML протокол. Порт YYY
PD>При обращении к серверу a.com, поддерживающему XML протокол, надо ему передать некий "приветственный" XML. По порту YYY. PD>В ответ он , если жив, пришлет XML-ответ (аналог 200 OK) PD>После этого ему шлется произвольный XML на порт YYY. С запросом. Там не надо никаких страниц указывать. Там запрос на АПИ, который сервер a.com опубликовал. (Для получения этого АПИ надо ему послать XML запрос с единственной командой — дай АПИ)
PD>Где в моей модели URI ? Кроме имени хоста, ничего не надо.
Открывает порт. Допустим, 80-ый. Пишем туда данные. Допустим, пары ключ=значение. При желании — можем и XML записать. Сервер нам отвечает. Не в XML, правда, но может и в XML если надо.
Кроме имени хоста, ничего не надо.
Как же называется этот протокол? Может быть, HTTP? А может, REST? А может, SOAP? Или XMLRPC? Упс. Где-то я это уже видел. И в чем добавленная стоимость вашего решения? В чем ценность?
PD>Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.
Я понял, вы SOA изобрели. Через пять или шесть лет после Sun, IBM и Bea. Осталось понять, как заставить владельца a.com предоставлять API, что бы вы в своем клиенте захотите его сайт использовать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
PD>>>Не утрируй. Почему есть HTTP протокол поверх TCP/IP и почему не может быть XML протокола поверх TCP/IP ? Для передачи XML нужна командная строка и параметры в ней отделять знаком & ?
M>>?????????????????????????
M>>Где это XML разделяется знаком & ???????????
PD>Слушай, что с тобой ? Ты меня совсем понимать перестал. Я говорю, что XML передается сейчас с помощью HTTP, а для запроса нужна командная строка с этими &.
Совсем не обязательно. Это — детали реализации того или иного сервиса.
PD>Вот такое можешь себе представить ? PD>Появился XML протокол. Порт YYY
PD>При обращении к серверу a.com, поддерживающему XML протокол, надо ему передать некий "приветственный" XML. По порту YYY.
PD>Где тут командная строка ? Где тут адрес страницы ? Где вообще страницы ? Где HTML ? (хотя. конечно, может быть, на некий запрос придет ответ в виде XML с CDATA, содержащем HTML). Где тут место HTTP ?
Сервер c.com может точно также посылать запросы другим серверам. Не обязательно по HTTP. Он точно так же может подсоединиться к серверу b.com по порту YYY, получить данные, обработать, отдать клиенту. В чем проблемы-то?
А если сервис b.com реализует десяток разных сервисов? Каждый навешиваем на свой порт? Или каждому передаем разные параметры при запросе? Чем это отличается от командной строки?
Более того, при POST-запросе никаких раделителей & может и не быть (чаще всего и нет), все происходит абсолютно аналогичным способом
M>>Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента.
PD>Где в моей модели URI ? Кроме имени хоста, ничего не надо.
Имя вызываемого сервиса нам нужно? В моей модели мы сразу вызываем сервис и передаем парметры. В вашей модели мы должны сообщить сервису, что мы вызываем такую-то и такую-то службу. Тот же URI, вид сбоку
>>Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т.д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
PD>И на здоровье. Если надо в ответ прислать просто текст на китайском — шлите. Картинку в jpg — шлите. HTML — шлите. Но в ответе в виде элемента XML ответа.
Почему обязательно XML?
M>>Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
PD><skipped>
PD>Спасибо за объяснения. См выше.
Вы бы почитали, что ли. Чем ваш самописный протокол отличается от стандартного HTTP-протокола?
PD>>>Я что-то не понял. Это web-приложение, если ему понадобится получить оперативный доступ к нажатиям клавиш (игра, допустим) сумеет установить low-level keyboard hook с помощью SetWindowsHookEx под линуксом ? Или все же ему придется как-то иначе ?
M>>Какой low-level keyboard hook с помощью SetWindowsHookEx?????
PD>Обыкновенный. Твое web-приложение — это игра, динамическая. В Windows, допустим, можно поставить этот хук на клавиатуру, если надо.
M>>onKeyPress в Яаскрипте уже отменили?
PD>Батенька, ну не надо так. Фокус с приложения уйдет — ничего не получишь. А я хочу. чтобы мое приложение реагировало на нажатия клавиш, даже если оно не в фокусе.
В топку такое приложение. Советую взять ближайшую игру и нажать Alt-Tab. Оппаньки фокус потеряли и в игру больше никакой нажатие не передается
M>>Работу с клавиатурой в Флэше уже отменили?
PD>Флэш — это ActiveX . Исполняемый код, с вашего позволения. Встроившийся в IE, верно, но все же это EXE (DLL).
M>>Еще раз. Веб-приложение — это сраница плюс сервер. Одно изменяется соответственно другому. С какого перепугу вдруг на странице появятся новые формы ля введения данных, если на сервере для них не будет логики, их обрабатывающей?
PD>А просто на том основании, что в моем понимании веб-приложение должно быть просто приложением, имеющим доступ к внешним источникам. И как в любом просто приложении в нем могут происходить самые разные действия, в частности, приводящие к изменению внешнего вида. А сервер мне тут нужен только как источник данных
Тогда мы говорим о десктоп-приложении, а не о веб-приложении
M>>Еще как аргумент. Сколько времени и денег потребуется, чтобы разработать десктоп приложение, работающее на: M>>Windows 2000 M>>Windows XP M>>Windows Vista M>>Windows Mobile 5 M>>Windows Mobile 6
M>>всех дистрибутивах Линукса
M>>MacOS X M>>MacOS X for iPhone
M>>Symbian
M>>Andorid
M>>Qtopia M>>OpenMoko
M>>и т.п.
PD>Да разработаны же они! Та же Mozilla, к примеру.
И много таких приложений? И где мозилла на моем Сони-Эрикссоне?
PD>Денег — да. Времени — да. Но мы, кажется, вопрос все же про архитектуру и идеологию начали, нет ? Я и не утверждаю, что мое решение реально можно завтра пустить в ход. Все аргументы насчет денег и средств принимаю. Насчет сроков тоже.
PD>Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.
Обоснования кривизны архитектуры в этом топика так приведены и не были
M>>О, в квартире можно поставить сервер, хранящий информацию терабайтами? 0_о
PD>Ну не смеши ради бога. Что это такле на c.com в его нынешней версии есть, что требует терабайтов ?
Терабайты я конечно загнул, но логика приложения будет очень сильно нетривиальной. Смысла ее держать на клиенте нет вообще. А если мы делаем тонкого клиента, то разницы между тонким клиентом практически не остается (за исключением того факта, что дестоп клиент заведомо сложно или невозможно портировать на такое же количество платформ)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да разработаны же они! Та же Mozilla, к примеру. Денег — да. Времени — да. Но мы, кажется, вопрос все же про архитектуру и идеологию начали, нет ? Я и не утверждаю, что мое решение реально можно завтра пустить в ход. Все аргументы насчет денег и средств принимаю. Насчет сроков тоже.
PD>Но все эти аргументы, хотя вполне годятся для практической аргументации, не годятся в качестве опрадания кривой архитектуры в принципе. А только об этом я и говорю.
Архитектура определяется только практическими соображениями. Всегда.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
WF>>Серьезно? А у меня не обновляется, вот незадача. Более того, у меня прав-то даже нет его обновить! А запускается он, естественно, с моими правами.
PD>Ну и что ? Это аргумент в теоретическом споре ?
Где ты здесь теоретический спор нашёл? Доказательство положений "правильно" и "не правильно", путём приведения аргументов "надо", а также поиск ответа на вопрос "куды котимся?!" — это теоретизирование, что ли? Где теория?! Дайте мне теорию срочно!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Так, ладно. Я уже не в силах отвечать всем, так что изложу свое видение и на этом на сегодня закончу. Собственно, я его уже изложил.
PD>Решение с клиентом
PD>Клиент выдает на экран форму, в которой запрашивается название продукта и адрес получателя. Эта форма не получена ни с a.com, ни c b.com, а просто принадлежит клиентному приложению. После нажатия Submit клиентное приложение берет название и отправляет серверу a.com. Получив ответ от него, оно берет полученные данные, добавляет к ним адрес получателя и шлет серверу b.com. Полученный от него ответ возвращается пользователю.
Немного уточню.
Предварительно еще раз напоминаю — речь идет об архитектуре. О том, правильная она или нет. Правктические соображения, все вместе взятые, весьма существенны, но мы-то все же об архитектуре спор этот затеяли. Так что вопросы стоимости и т.д. я не рассматриваю.
Итак.
Клиент выдает на экран форму, в которой запрашивается название продукта и адрес получателя. Клиент — либо EXE, либо JAR либо не знаю что еще.
Серверы имеют свой АПИ. Этот АПИ создается одновременно с созданием сервера. Этот АПМ базируется на XML (к примеру) и позволяет формировать те или иные запросы к серверу. При этом серверу передается только XML, в котором полностью и описывается запрос. Сервер также умеет возвращать XML с описанием своего АПИ. (В скобках — сервер, возможно, дает еще и утилиту API Builder)
Этот АПИ может расширяться, может и сужаться, но всегда остается в консистентном состоянии. Аналогично Win32 API, который хоть и не раз изменялся, но все же при этом прежние возможности либо продолжают поддерживаться (в большинстве случаев), либо объявляются deprecated и реально исполянются другой частью АПИ, либо отменяются, в последнем случае сервер при попытке вызвать этот АПИ возвращает отказ.
Для работы с этим АПИ используется некий XML протокол поверх TCP. Для обращения к серверу единственное, что надо знать — его имя. Далее ему шлется некий XML с запросом, он шлет XML с ответом и т.д. Никакого знания о внутреннем устройстве сервера вовне не дается, так что его можно переносить на другую платформу или вообще полностью переработать. Никакие явные ссылки на внутренность сервера не существуют. Необходимо только поддерживать АПИ.
Клиент либо уже работал с этим сервером, либо нет. Если нет — он первым делом запрашивает его АПИ. Возможно АПИ будет достаточно сложным или многоуровневым, так что детали здесь требуют уточнения. Но для большинства коммерческих сайтов он слишком сложным не будет. Например, сайт туроператора. Запросы могут быть по странам, датам, отелям, самолетам и т.д. Ничего в приницпе тут нового нет и не будет, а если что-то поменяется — будет новая версия АПИ при том. что старая поддерживается.
Если клиент имеет АПИ, он строит на его основе запрос к серверу. Это может быть сделано даже автоматически, так как АПИ разных серверов хоть и различен, но в основе его лежит унифицированный формат, XML, так что пострение запроса , в общем, может делаться одним или почти одним и тем же способом.
Сервер, получив запрос на родном ему АПИ, исполняет этот запрос. Если при этом возникают ошибки, он изготавливает ответ с XML, содержащем описание ошибки. В противном случае он возвращает XML с ответом.
Клиент, получив этот ответ, парсит этот XML с помощью DOM/XPath или иначе. Там не может быть ничего постороннего, так как клиенту известен АПИ, и , стало быть, известно, что сервер может вернуть. Для решения проблемы с версиями достаточно указать версию в запросе и в ответе — естетсвенно, тоже в виде тега XML. Если клиент все еще для АПИ 1.2, то он и сообщит об этом, посылая запрос, что будет означать для сервера, что и ответ надо вернуть в рамках 1.2, а не 1.3. Но в ответе можно еще и сообщить, что 1.3 существует. Клиент, получив такое, может инициировать свой апгрейд.
Ну а дальше уже парение в облаках. Существует google2, который не изучает HTML страницы серверов (о других функциях я не говорю сейчас), а запрашивает у них их АПИ. Используя на google2 мощные аппаратурные средства, производится анализ этих АПИ и реализуется внешний интерфейс, по которому все желающие могут получить информацию о том, какие АПМ существуют, где они находятся, их версии и т.д. Эту информацию приложения (хоть web, хоть не web) могут запросить и использовать для определения, к кому надо обратиться и с каким запросом. Парение в космическом пространстве — google2 принимает запрос на естественном языке и формирует N вызовов АПИ разных серверов, которые и передаются клиенту, а ему остается эти вызовы только реализовать.
Про HTML. Его никто не предлагает отменять. В XML ответе может слаться все, что угодно, в том числе и некий текст в некотором формате, который предназначен для его показа некоторым окном, именуемым окном броузера. XML ответ , содержащий TIFF файл, может быть использован для показа его в некотором графическом редакторе/вьюере. И т.д.
Я прекрасно понимаю, что реальных шансов на широкомасшатбный переход к этой модели нет в ближайшем будущем. Я прекрасно вижу всякие стоимостные проблемы, проблемы безопасности и т.д. Но ведь мы архитектуру обсуждаем, не так ли. Поэтому прошу именно архитектуру и критиковать.
Ну а в заключение пара слов о реальности такого.
1. Skype. Бесспорно, десктопное приложение. В то же время очевидно, что это Интернет приложение. Вот что мне сейчас tcpview о нем показал
Skype.exe:1040 TCP divsoft:60801 117.8.238.206:4020 ESTABLISHED
Skype.exe:1040 TCP divsoft:60801 154.business-link-static.sovintel.spb.ru:60721 ESTABLISHED
Skype.exe:1040 TCP divsoft:1609 83.167.103.156:13915 ESTABLISHED
Skype.exe:1040 TCP divsoft:60801 divsoft:0 LISTENING
Skype.exe:1040 TCP divsoft:60801 fat.omsk.ru:1212 ESTABLISHED
Skype.exe:1040 TCP divsoft:60801 host-195-49-170-70.avantel.ru:50941 ESTABLISHED
Чего ему на 154.business-link-static.sovintel.spb.ru или host-195-49-170-70.avantel.ru нужно — понятия не имею. Может, эти хосты и не связаны логически, то есть с каждым он работает независимо. Может, он комбирирует данные полученные от них. Не знаю. Но работает он именно по этой модели, хотя XML тут или что-то иное — не знаю.
2. Desktop Weather. Аналогично
DesktopWeather.exe:1204 TCP divsoft:1684 i.imwx.com:http ESTABLISHED
DesktopWeather.exe:1204 TCP divsoft:1685 desktopfw.weather.com:http ESTABLISHED
3. SQLYog для MySQL. Чисто десктопное приложение. Запросы к БД делает по 3306 и шлет их не знаю по какому протоколу, но назову его условно SQL протоколом (не придирайтесь!) Я как-то смотрел его пакеты в сниффере, кое-что понять можно, хотя он не текстовый. Так или иначе, по некоторому протоколу шлется запрос, в котором то ли SELECT-INSERT, то ли что-то иное, не важно. Об АПИ клиент с севером давно договорились, а не договорились бы заранее — пришлось бы запрашивать протокол.
Обратите внимание, что нигде в приведенных примерах 80 порт и HTTP не используется. Между тем Desktop Weather имеет вид, вполне похожий на вид web-приложений — гиперлинки, табы и т.д. Отрабатываются эти гиперлинки в пределах самого Desktop Weather, если они к нему относятся, а если нет — открывают окно броузера.
4. Ну и последнее. То, чем я сейчас занят. Если в общем виде — некая система взаимодействующих серверов и клиентов с протоколом их взаимодействия. Увы, бинарным пока что. Вот мы и учим эту систему XML понимать, чтобы новые серверы/клиенты могли с прежней системой взаимодействовать. Никаким HTTP там и не пахнет. Подробностей не будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Предварительно еще раз напоминаю — речь идет об архитектуре. О том, правильная она или нет. Правктические соображения, все вместе взятые, весьма существенны, но мы-то все же об архитектуре спор этот затеяли. Так что вопросы стоимости и т.д. я не рассматриваю.
Тогда обсуждение не имеет смысла. Потому что архитектура ПО производна от стоимости, сиречь усилий для разработки и поддержки. Никаких "вообще правильных" и "вообще неправильных" архитектур не бывает в природе. Все правильности всегда можно объяснить прагматически, все неправильности — аналогично.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
PD>Я прекрасно понимаю, что реальных шансов на широкомасшатбный переход к этой модели нет в ближайшем будущем. Я прекрасно вижу всякие стоимостные проблемы, проблемы безопасности и т.д. Но ведь мы архитектуру обсуждаем, не так ли. Поэтому прошу именно архитектуру и критиковать.
Непонятен ровно один аспект. Зачем всё это? Какую выгоду это даёт? Чем это лучше существующей ситуации?
Здравствуйте, Hobot Bobot, Вы писали:
HB>Так где все-таки подробное описание соответствующего клиентского приложения? С описанием методов получения и интерпретации данных с a.com и b.com?
Кое-что любопытное в твоём постинге, тем не менее, есть, но отпишусь позже. Где-то через полсуток.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Так, похоже, говорить больше не о чем. Все ясно. Ты базируешь свой метод на анализе существующей страницы и применяешь малоубедительные эвристики для такого нахождения данных, и не задумываешься, что все это полетит к чертовой матери, если дизайнер сайта решит там слово поменять. Обсуждать такое решение я не намерен.
ГВ>Э... А это не твой ли десктоп собирался вынимать данные из того же a.com?
Он. Впрочем, десктоп они или нет — зависит от того, как посмотреть. Приложение, в общем. Может, EXE, может, JAR, Может, еще что-то...
>Ты уж как-то определись сам: стабильный API у этих серверов или нет. А то говоришь, что он не стабильный — плохо; говоришь, что стабильный — тоже плохо. На худой конец, чётче сформулируй граничные условия, что ли...
С моей точки зрения, витание в облаках начинается гораздо раньше, чем это указано в тексте.
Возражения:
1. Никаких ПРИНЦИПИАЛЬНЫХ отличий предполагаемого подхода от существующих решений на базе HTTP я не увидел. HTTP точно так же позволяет "ничего не знать о внутреннем устройстве сервера"; использовать строго заданный API; передавать описание API и т.д. и т.п. Так работают eBay, PayPal и много-много других сервисов.
2. Вы говорите об обсуждении архитектуры — и тут же начинаете описывать детали реализации, причем реализации неудачной. XML в качестве универсального формата не подходит хотя бы потому, что он исключительно текстовый. Tiff внутри XML — это будет не просто ужас, а ужас-ужас.
3. Приведенные Вами примеры никак не иллюстрируют Вашу точку зрения. Вы рассуждаете об универсальном протоколе и приводите в пример приложения, использующие протоколы крайне узкоспециализированные.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
. Исполняемый код, с вашего позволения. Встроившийся в IE, верно, но все же это EXE (DLL).
То же самое, вид в профиль — это если даже закрыть глаза на то, что XML никак не подходит для двоичных данных, и чтобы впихнуть туда картинку, придется заниматься извращениями и раздувать пересылаемые данные в полтора-два раза.
