Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>Ну и в моем запросе я говорю: хочу слона (item=elephant), предпочтительно розового (preference=pink)
M>>А чем отличается иерархический запрос, я, честно говоря, не понял
PD>Сформулируй (например, для Гугла) запрос вида
PD>Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.
Угу, а предлагаемый нами некий Универсальный Уравнитель это поможет нам сделать?
Такой запрос в общем случае нельзя составить. И никакой язык запросов нам в этом не поможет.
И HTTP здесь не причем. Потому что я могу составить параметры и отслать их POST'ом на мой сервер, пусть он корячится
А для гугла просто нет такого понятия, как приоритет. Но вот на hotels.de можно задавать запросы типа "Цюрих +/- 10 километров". Чем не ограничение? Проблема далеко не в запросе, а в том, как этот запрос обрабатывать
Здравствуйте, Mamut, Вы писали:
M>Угу, а предлагаемый нами некий Универсальный Уравнитель это поможет нам сделать? M>Такой запрос в общем случае нельзя составить. И никакой язык запросов нам в этом не поможет.
Почему нельзя ? Запрограммировать ты это бы смог — на С#, на Java, на чем хочешь. С таким же успехом можно это изложить средствами некоего иеррархического языка запросов
M>И HTTP здесь не причем. Потому что я могу составить параметры и отслать их POST'ом на мой сервер, пусть он корячится
Я же писал, что вопрос HTTP меня больше не волнует. Прочти внимательно.
M>А для гугла просто нет такого понятия, как приоритет.
Именно. Вот поэтому он сотни тысяч ответов даст, если туда сунуть слон розовый мамонт Сибирь самка... И даже Advanced Search не поможет. >Но вот на hotels.de можно задавать запросы типа "Цюрих +/- 10 километров". Чем не ограничение? Проблема далеко не в запросе, а в том, как этот запрос обрабатывать
Чтобы его обработать, надо найти подходящий язык. чтобы его сформулировать. Обычный поиск тут не работает
M>>Угу, а предлагаемый нами некий Универсальный Уравнитель это поможет нам сделать? M>>Такой запрос в общем случае нельзя составить. И никакой язык запросов нам в этом не поможет.
PD>Почему нельзя ? Запрограммировать ты это бы смог — на С#, на Java, на чем хочешь. С таким же успехом можно это изложить средствами некоего иеррархического языка запросов
А причем тут запрос тогда?
К нам на сервер приходит запрос в каком-то виде, который мы понимаем. Мы его обрабатываем и возвращаем результат. Так ведь?
Тогда все равно, что за запрос — лишь бы принимающая сторона его понимала. А один общий язык описания запросов придумать все равно не удастся — слишком много разных задач и разных запросов
M>>И HTTP здесь не причем. Потому что я могу составить параметры и отслать их POST'ом на мой сервер, пусть он корячится
PD>Я же писал, что вопрос HTTP меня больше не волнует. Прочти внимательно.
M>>А для гугла просто нет такого понятия, как приоритет.
PD>Именно. Вот поэтому он сотни тысяч ответов даст, если туда сунуть слон розовый мамонт Сибирь самка... И даже Advanced Search не поможет.
Ну, если мы гвоорим о сферовакууме (а ведь мы уже не говорим ни про HTTP, ни про декстоп, а вообще непонятно о чем), то этот uberGoogle спокойно будет возвращать требуемые результаты в нужном формате.
То, что возвращает некий сервис полностью лежит на совести разработчика и никакой язык запросов тут не поможет.
>>Но вот на hotels.de можно задавать запросы типа "Цюрих +/- 10 километров". Чем не ограничение? Проблема далеко не в запросе, а в том, как этот запрос обрабатывать
PD>Чтобы его обработать, надо найти подходящий язык. чтобы его сформулировать. Обычный поиск тут не работает
?
Я захожу на hotels.de, там есть один инпут: название_города и один селект: расстояние
При чем тут подходящий язык? На серверной стороне к нам придет два параметра: название_города и расстояние.
Вернемся к предлагаемой задаче:
Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.
Решить ее не поможет никакой язык запросов, потому что кто-то где-то должен запрограммировать нечто, что должно обрабатывать (парсить, анализировать и т.п.) этот запрос.
А форматов этого запроса только для XML — десятки. И что?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Почему нельзя ? Запрограммировать ты это бы смог — на С#, на Java, на чем хочешь. С таким же успехом можно это изложить средствами некоего иеррархического языка запросов
Непонятно, что такое "иерархический". Тот запрос, который ты попросил, в нем никакой иерархии нету.
Если ты считаешь дизъюнкции и конъюнкции предикатов иерархией — флаг в руки.
PD>Чтобы его обработать, надо найти подходящий язык. чтобы его сформулировать. Обычный поиск тут не работает
Таких языков есть. Я в свое время интересовался тем, какие вообще запросы люди делают.
В результате пришел к выводу, что универсальный язык если и можно построить, то выполнение запросов в нем за приемлемое время получить удастся уже вряд ли.
Удобнее под каждую задачу строить свой микро-язык.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Пришлось очень много думать и фильтровать. Скоро расшифрую, что за этим стоит (уж коль скоро обещался ответить чуть раньше). Пока в двух словах: в основном размышлять пришлось над вот этим:
PD>О семантике. Она, как всегда, за сценой и плохо формализуема.
На этом месте я выхлюпал 150 коньяку и продолжил думать. То есть это не нечто шокирующее, это оказалось много круче.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Твой постинг я разделил на три сильно неравных части: две из них состоят, преимущественно, из аналогий, и одна содержит ключевой, вопиющий, смысловой пропуск. С неё и начну.
PD>О семантике. Она, как всегда, за сценой и плохо формализуема. Ты писал
ГВ>>что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.
Павел, я это не случайно писал. Здесь как раз — главный момент.
PD>Да, конечно, без согласования толку не будет, но в этом согласовании могут участвовать клиент и сервер. Возьмем опять SQL сервер. Если мы ничего не знаем о БД, то мы даже SELECT * FROM сделать не можем, поскольку не знаем FROM что. Но SQL сервер готов нам помочь, вернув свою схему, для этого надо только знать, где он находится, больше ничего. Схема определяет предметную область (об этом ниже) и структуру базы (сервера), и ее анализ, вообще говоря, позволить делать вполне осмысленные запросы. Тут есть и роль сервера, и роль клиента. Сервер вполне может представить эту схему не в виде DDL, а в чем-то более интеллектуальном, вроде объектного графа. Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.
Для начала, попробуй сравнить два высказывания: "Схема [базы данных] определяет предметную область" и "Схема [базы данных] определяется предметной областью". Разницу понимаешь. Даже на таком простом уровне, как схема базы данных уже вовлекается масса предположений о действительной структуре (sic!) символического пространства предметной области. При этом схема базы данных неизбежно содержит какие-то допущения и аппроксимации.
Иными словами, не надо ставить лошадь позади телеги. Первостепенной задачей анализа предметной области является, как раз, определение символического пространства и соответственно, допустимого набора связей этих символов. Собственно в этом и заключена "семантика" предметной области. Не свосем, конечно, но в принципе дело обстоит именно так. Миф о том, что программист способен понять любую предметную область имеет под собой вполне реальные основания: мы работаем, прежде всего, с символическим пространством. А относится оно, скажем, к нефтепромыслу или к автопрому, или к нюансам Oracle — не суть важно.
Итак, мне пришлось констатировать, что ты пропускаешь в своих рассуждениях основополагающую часть — символы, интерпретирующие семантику. Семантика, это что такое, вообще говоря? Да те же символы, что и во всех прочих случаях. Команды процессора, инструкции языка программирования, или, что наиболее важно в контексте этой беседы, — элементы сети, определяемой вербальными символами из словаря Ожегова (если мы говорим о русскоязычном пространстве).
Я вполне допускаю, что "розовый слон" может означать "никакой тяжёлой дури в радиусе 200 метров!" или ещё что-то в этом духе. Проблема в том, как передать это знание компьютеру. Компьютер "понимает" воплощённые символы и только их (в чём его преимущество перед людьми, если разобраться). Ответ здесь, в принципе, так же очевиден, как и сложен технически: нужно закодировать всё символическое пространство, которым оперирует конкретный пользователь, то есть перевести "абстрактные" символы в их специфическое воплощение и отсюда уже начать разворачивать сугубо технические вариации на тему клиент-сервер, HTTP-XML и иже прочая еси аки и наипаче.
PD>За сценой пока что остался смысл всего этого. Тут я возвращаюсь к твоему примеру с tiff
[overquotting died forever]
PD>Все так. Кстати, это же верно и для запросов. Ну подадим мы на запросе PD>type=elephant&color=rose.
PD>Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.
Бу-га-га. Гугль, не к ночи будь помянут, ищет полнотекстовым поиском. AFAIK, такими фишками, как семантической интерпретацией они не заняты.
PD>Но в действительности все далеко не так плохо обстоит. Гарантии , конечно, нет, но, положа руку на сердце — тебе часто встречались .tiff файлы, содержащие не картинку ? Может, и встречались, но вряд ли часто. Идея расширений на удивление хорошо работает. Я сам брошу камень в того, кто предложит по расширениям однозначно судить о содержании файла, но ведь в 99.9% случаев это верно!
НО! Это плод того, что масса людей, формирующих файлы .tiff придерживаются этого соглашения. Это очень важно: наличие некоего документа (не обязательно в виде RFC), определяющего наполнение того или иного символа и соблюдение положений этого документа людьми. В рассматриваемом случае с браузером, если на месте .tiff окажется вот этот постинг, то браузер отбросит его как неправильный .tiff.
PD>По существу расширения — это некий лексикон, вошедший в большинство современных естественных языков (не всех, я совсем не уверен, к примеру, насчет LANGUAGE_MUMBO_JUMBO . А и в пределах самого языка «слон» — это, как правило, все же животное известного вида с хоботом, а не что-то иное. Это не работает на 100%, несомненно, но, в общем, работает. А делая запрос к Гуглу, мы это как-то учитываем ? Точнее, Гугл как-то разбирается в том, что , найдя на странице розового слона, надо проанализировать текст и на основе этого анализа отнести страницу к тем, которые надо выдавать на запрос «вечеринка выпивка» ? Вряд ли
Естественнно, google не разбирается в семантике. Я могу ошибаться, но, кажется, догадываюсь, в чём причина. Дело в том, что семантика тех или иных символов может в некоторой степени флуктуировать для тех или иных пользователей. Ну, например, я ищу розовых слонов, но не откажусь узнать, где устраивают вечеринки без тяжёлой дури. Кстати, здесь я цепляю очень сложную тему с "не откажусь". Я как бы не "за", но и не "против". Можно с лёгкостью перечислить, что именно нужно, но невероятно тяжело перечислить всё, от чего пользователь не отказалcя бы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Теперь много об аналогиях. Здесь я буду выступать в своеобычном апмлуа сетевого комментатора. Знаешь, вероятно, эдакий истерично-критиканский стиль.
PD>com.a.html.product(type=elephant,color=rose)
PD>То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры.
Болт! Сайт в данном случае ничего не экспонирует. Окромя допустимых аргуметов "type" и "color". Речи о ынутренней структуре тут и быть не может.
PD>Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.
Погоди. Не надо натягивать презерватив на покрышку. Это и не класс, и не методы. Это всего лишь поисковые запросы. Именно так к ним и следует подходить. Они по определению не претендуют на то, что их результат окажется стабильным в долговременном представлении.
PD>Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели.
Ха! Ну-ка, ну-ка, спецификацию модели в студию! Понимаешь, что имею в виду?
PD>Меня интересует в первую очередь слон, а уж потом розовый. Если розового слона не будет, я готов и другим (может быть) удовлетвориться, но стихи о розовом небе мне не нужны. Здесь не AND и не OR, здесь иерархия. Это же касается поиска.
О, как! Вот раз тебя интересует в первую очередь слон, как представитель млекопитающих-с-хоботом, то вот так об том и скажи. Компьютеры, они в Америке придуманы, а следовательно — ту-у-у-упы-ы-ые!
PD>Результат этого вызова отсылается в броузер. По существу этот результат есть смесь того, что может анализироваться только с помощью естественного интеллекта (или пишите анализатор текста на естественном языке)
В десятку! Да! И ещё не забудьте модель человека, как связной системы семантик, метасемантик, и мета-мета семантик.
PD> и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером).
Да какая разница — клиент это или сервер?
PD> Ввиду отсутствия четких правил и наличия различных клиентов под разными ОС этот код неизбежно вынужден ограничиться неким минимумом возможностей, которые можно использовать на клиенте. Тем не менее удается написать такой код, который в состоянии нарушить корректную работу клиента, поэтому клиент вынужден принимать меры по блокировке части этого кода, что, впрочем, плохо удается, так что в итоге ОС вынуждена принимать меры по защите от самого клиента (Vista, выполнение IE под юзеровской УЗ).
Повторюсь: пошёл он подальше, это самыый браузер. Без него управимся. Смартового напишем.
PD>Если рассмотреть web-сервисы, то тут картина уже несколько иная. Документированы списки методов и их параметры, документирован результат. Отсюда возможность вызывать эти web-сервисы не только из стандартного клиента (броузера), но и из произвольного для данной цели написанного клиента.
Э-э-э, батенька! Так "произвольного" или "для данной цели"? Эти явления нельзя смешивать. И с другой стороны, возьми, к примеру, WSDL с некоего сайта по имени www.rsdn.ru (вспомнилось вдруг, вообще — забыл даже, что там такое лежит), да попробуй расшифровать, что означают параметры методов и что с ними имеет смысл делать.
PD>Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет
Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API. Ну, то есть, имеет, конечно, но весьма опосредованное. Во-вторых, тезис об экспонировании внутренней структуры имеет смысл только по отношению к некоторым объектам уровня интерпретации. Например, я понятия не имею (да и знать не хочу), что скрывается за дескриптором сокетов. Мне, как пользователю, важно, чтобы соглашения об использовании и допустимой последовательности вызовов соблюдались разработчиками sockets.
PD>А теперь рассмотрим SQL-сервер. Это тоже сервер , но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов
PD>А мог бы ? Мог. Вот представь себе
PD>[SQLMethod] // PD>string[] GetColumnStrings(string database, string table, string column); // SELECT COLUMN PD>string[][] GetColumnsStrings(string database, string table, param string[] column) // SELECT COLUMN1, COLUMN2...
PD>string[] GetColumnStringsByCondition( string database, string table, string column, cond condition, string value); // SELECT COLUMN... WHERE
PD>и т.д.
Представил. Содрогнулся.
PD>Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.
Не совсем так. Ты постоянно, как я уже говорил, пытаешься натянуть презерватив на покрышкку, то есть расширить значение терминов до невероятных ширшот (или — широтей). Это неправильно. API — это интерфейс прикладных программ. Набор символов, допустимых в SQL-запросах, это и есть только набор символов, допустимых в SQL-запросах.
PD>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных.
Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся!
PD>Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.
Стойка обретает суровую стабильность...
PD>А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов. При этом сайт а)полностью скрывает от внешнего мира свою структуру, б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.
Ничего подобного. Здесь у тебя такой вагон допущений, что всё перечислять — времени жизни вселенной не хватит.
PD>Так что вызов сайта в этой модели выглядит так PD>com.a(XML request)
PD>для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно. 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
PD>Вот, собственно, зачем мне тут понадобился XML. Собственно, мне не XML нужен, мне язык иерархических запросов нужен, и мне показалось, что XML для этого подходит. Я за XML стоять горой не буду, мне, в общем, все равно, лишь бы можно было запрос сформировать.
Дык. Я вообще не могу представить для описания иерархических структур ничего лучше, чем S-expressions. XML — ну, я уже отписывался по этому поводу. Бастард и бастард, ничего более.
PD>О протоколе. Это действительно маловажно. Если оставаться в рамках XML, то можно прекрасно обойтись без HTTP, Заменив его на XMLTP . Если же считать HTTP частью транспорта, то можно и с ним. Иными словами, вполне приемлема схема с протоколом прикладного уровня XML, работающим поверх транспортного протокола HTTP/TCP/IP.
Ну это вообще задача -10-го порядка значимости.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
про попытке вставить в Open Office Writer привело к безвременной смерти последнего. Эффект стабильный, пробовал 2 раза. Все же вставил и распечатал. Буду думать. Ответ не сегодня.
PD>про попытке вставить в Open Office Writer привело к безвременной смерти последнего. Эффект стабильный, пробовал 2 раза. Все же вставил и распечатал. Буду думать. Ответ не сегодня.
Интересно. Я, конечно, недолюбливаю Open Source, но не до такой же степени. У меня вставилось, версия 2.3.1.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
По мелочам отвечу. С чем согласен — просто опустил.
PD>>То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры.
ГВ>Болт! Сайт в данном случае ничего не экспонирует. Окромя допустимых аргуметов "type" и "color".
Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект. Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ? Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?
>Речи о ынутренней структуре тут и быть не может.
Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ? product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.
ГВ>Погоди. Не надо натягивать презерватив на покрышку. Это и не класс, и не методы. Это всего лишь поисковые запросы.
Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй.
Я думаю, ты понимаешь, что я не предлагаю садиться и эти классы писать. Это только модель для рассуждений. Но если она неверна — объясни, почему.
>Именно так к ним и следует подходить. Они по определению не претендуют на то, что их результат окажется стабильным в долговременном представлении.
И что ? А для обычных, классических функций всегда гарантировано сохранение результата во времени ? Не говоря уж о рандомах, но возьми, к примеру, алгоритмы оптимизации. Изменили метод оптимизации — получили малость другой результат. Я уж не говорю, скажем, о функциях вывода на печать — тут очень многое может измениться.
PD>>Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели.
ГВ>Ха! Ну-ка, ну-ка, спецификацию модели в студию! Понимаешь, что имею в виду?
Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!
PD>> и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером).
ГВ>Да какая разница — клиент это или сервер?
Так я и говорю, что никакой. Разница та же — что и вызове callback в обычном приложении. Детали реализации.
PD>>Если рассмотреть web-сервисы, то тут картина уже несколько иная. Документированы списки методов и их параметры, документирован результат. Отсюда возможность вызывать эти web-сервисы не только из стандартного клиента (броузера), но и из произвольного для данной цели написанного клиента.
ГВ>Э-э-э, батенька! Так "произвольного" или "для данной цели"?
Не пойдет. Именно произвольного (т.е не обязательно броузера, а что захотим, то и напишем, и какими средствами захотим , такими и напишем, и будет он десктопным или нет — как захотим), но для данной цели. Если я писал в свое время такой клиент для задач оптимизации финансовых расчетов (реализуемых сервисом), то для задач предсказания погоды он не пойдет. Но мы этот клиент делали как десктопное приложение (для отладки), как код, вызываемый их Excel и т.д.
А вот если бы этот сервис вернул мне javascript, то пришлось бы либо исполнять это только из броузера, либо писать свой интерпретатор javascript и надеяться, что в ответе будет только часть, относящаяся к задаче, а не window.open(...), в противном случае придется свой броузер писать. Вот и все, что я хотел здесь сказать.
>Эти явления нельзя смешивать. И с другой стороны, возьми, к примеру, WSDL с некоего сайта по имени www.rsdn.ru (вспомнилось вдруг, вообще — забыл даже, что там такое лежит), да попробуй расшифровать, что означают параметры методов и что с ними имеет смысл делать.
Это к тому, что я распечатал и буду думать.
PD>>Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет
ГВ>Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API.
WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.
PD>>Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.
ГВ>Не совсем так. Ты постоянно, как я уже говорил, пытаешься натянуть презерватив на покрышкку, то есть расширить значение терминов до невероятных ширшот (или — широтей). Это неправильно. API — это интерфейс прикладных программ.
Можешь считать, что я расширяю это понятие до невероятных широт, если хочешь. То, что АПИ — интерефйс программ (и не обязательно прикладных) — это верно, но утверждать, что этот интерфейс должен состоять из описаний методов, типов и т.д — не согласен. Он может, вообще говоря, быть любым.
PD>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных.
ГВ>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся!
Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ?
PD>>Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.
ГВ>Стойка обретает суровую стабильность...
Зря ты эту стойку принял. Такое моделирование совершенно обычно в научных исследованиях. Допустим, что волновая функция молекулы есть суперпозиция волновых функций атомов. Простите, а с чего это вы такое допустили, из каких принципов волновой механики это следует ? Да ни из каких, но по ряду соображений можно предположить, что межатомные взаимодействия — эффект второго порядка. А поэтому упростим модель и посмотрим, что мы от нее можем получить. И получают ведь!
PD>>А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов. При этом сайт а)полностью скрывает от внешнего мира свою структуру, б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.
ГВ>Дык. Я вообще не могу представить для описания иерархических структур ничего лучше, чем S-expressions. XML — ну, я уже отписывался по этому поводу. Бастард и бастард, ничего более.
PD>>про попытке вставить в Open Office Writer привело к безвременной смерти последнего. Эффект стабильный, пробовал 2 раза. Все же вставил и распечатал. Буду думать. Ответ не сегодня.
ГВ>Интересно. Я, конечно, недолюбливаю Open Source, но не до такой же степени. У меня вставилось, версия 2.3.1.
Если вставлять из ФФ, то такой эффект довольно часто проявляется. Лучше вставлять через insert special -> unformatted text
Ну и последняя часть рассуждений — завершая спич об аналогиях. Я понимаю, что ты рассматриваешь только некоторые детали, представляющиеся тебе существенными в данном контексте, но ты вовлекаешь, тем не менее, довольно таки значимые явления, которые бесплатно разодрать на отдельные аспекты совсем нельзя.
PD>О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ?
Боже мой! На этот вопрос давать "общий" ответ нельзя по определению. Всё решается на месте.
PD>Ответ прост — если речь идет о вводе данных (стандартном действии), то для этого и надо использовать стандартный класс окон (диалоги), если же речь идет о действиях явно нестандартного вида, то надо создавать свое окно, тем более, что в диалоговых окнах некоторые возможности, легко и просто реализуемые в своих окнах, реализуются с трудом или вообще не реализуются (например, перехват сообщений в петле модального диалога реализуется только с вывертом, именуемым хуком, в то время как в своем окне он реализуется элементарно). То же и здесь. Если речь идет о вводе данных и отсылке их на сервер — незачем велосипед изобретать. Если же мы собираемся писать PhotoShop для сети , то работать он будет на клиенте, а для связи с сервером использовать некую часть, реализуемую с помощью стандартных средств (окна типа диалога, будет это окно частью иного процесса или же просто окном диалоговых интернет-окон — это не самое важное, хотя я склоняюсь ко второму). Так что клиент должен заниматься своим делом, а сервер своим. А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.
Павел, не ведись ты на общую вакханалию. Приложения всегда были и будут именно "просто" приложениями.
PD>И последнее. Сколько это будет стоить ? Сумасшедшие деньги. Без всякого сомнения. Будет ли это реализовано ? Не знаю. Знаю одно — нынешняя модель явным образом начинает переживать самое себя. Ее развитие, в силу заложенного в нее подхода, не соответсвующего объектной модели, ведет к тому, что в ней то и дело принимаются решения ad hoc, что приводит к появлению в ней заплат, а потом заплат на заплате. Раньше или позже сложность и внутренняя нелогичность этой модели превысит определенный порог, после чего появится некая белая мышь и погубит этих динозавров. Вполне возможно, что эта мышь будет совсем не похожа на то, что я описал.
Здесь нужно вернуться к части первой моих ответов. Есть очень глубокий и хитрый фокус, котрый подкинул Керниган сотоварищи всей програмистской братии — C ("Си") распространился практически сам по себе, вместе с Unix-ом (в отечественной интерпретации — МОС, если не ошибаюсь). Фокус состоит в том, что C существенно проще, чем, скажем PL/1, но тем не менее, обеспечивает всё то же самое, что позволял PL, плюс ещё... Блин, вспомнить бы PL из институтского курса. Не, не буду.
PD>В заключение один простой пример. [skip, 9x, NT, etc.]
Meanwhile Microsoft continued to develop Windows NT. The main architect of the system was Dave Cutler, one of the chief architects of VMS at Digital Equipment Corporation (later purchased by Compaq, now part of Hewlett-Packard). Microsoft hired him in 1988 to create a portable version of OS/2, but Cutler created a completely new system instead. (Наш человек! — Г.В.) Cutler had been developing a follow-on to VMS at DEC called Mica, and when DEC dropped the project he brought the expertise and some engineers with him to Microsoft. DEC also believed he brought Mica's code to Microsoft and sued. Microsoft eventually paid $150 million U.S. and agreed to support DEC's Alpha CPU chip in NT.
Иными словами, аргументы из серии "Linux логичнее, чем Windows и Windows его боится и боялся отродясь" отправляются в лес жарить шашлык. Более чем уверен, что на момент выпуска NT (см. также материалы по теме OS/2) её разработчики про Linux, может, и знали чего, но так... Мало ли курьёзов в IT? Студенты, они такие — всё время вселенную потрясти пытаются, ну и пущай себе пытаются.
С другой стороны, DOS, в принципе, это не более, чем монитор прерываний, а не операционная система. Отсюда мораль: она не могла стать ни современной операционной системой, ни какой бы то ни было существенной ОС вообще. Вся причина её успеха в том, что MS вовремя подсуетилась с заказом от IBM. Более того, согласись, забавно, что "современная ОС" по каким-то мистическим причинам недалеко ушла от ОС 70-х. Я имею в виду Unix. Тогда как куда как более моладая DOS уже предана повсеместному порицанию. Так что, не надо тасовать интерпретации фактов в угоду теории, это вредит и теории, и тасователю.
PD>И уж совсем в заключение. Заменив вызов PD>com.a.html.product(type=elephant,color=rose) PD>на PD>com.a(XML request) PD>можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид
Павел, да плюнь ты вообще на "классы" в частности и на "ООП" вообще. Чем дальше в лес, тем надёжнее я, например, прихожу к выводу, что "объектная ориентация" это очень большая подколка. Попросту говоря — тупиковая ветвь развития.
PD>Internet(XML request) PD>а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.
PD>Но я уже слышу топот копыт. Ко мне стремительно приближается сферический конь в вакууме и я начинаю ощущать вокруг себя ауру безвоздушного пространства. Так что развивать это направление не буду.
PD>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?
Вот честно, не догадался. Ослабел на догадки после разбора и многократного переанализа.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Поел и решил добавить — насчет АПИ. Приведу пример из своей практики.
Делал я в свое время одну БД. Ну БД — слишком громко сказано, некий файл со структурой, которую я точно так и не смог определить. Что-то вроде дерева списков подсписков множеств Но по сути — это была база некоторых данных, с запросами к ней. Отнюдь не реляционная. Собственно, и написание всего этого хозяйства было связано с иерархичностью данных, вследствие чего заказчик потратил чертову прорву денег при попытке реализовать это все в SQL сервере, а нужной скорости так и не получалось. Я предложил некоторые из запросов вынести в отдельный модуль и реализовать их самому. В начале там был простой текстовый файл, но когда им это понравилось и меня начали просить сделать еще и еще, я понял, что к задаче надо отнестись всерьез . Ну и еще известная всем моя склонность к оптимизации — я решил, что должен сделать в 2-3 раза быстрее, чем мне заказано. Могу ведь — почему не сделать ?
У этого хозяйства был вполне классический АПИ в виде одной-единственной функции, которой подавался указатель на структуру запроса и она возвращала данные ответа (в mmf), по которым можно было итерировать. В общем, ничего особенного. Классика.
Для тестирования этой классики мы соорудили клиента, который принимал текстовую строку в стиле SELECT-WHERE (в действительности синтаксис был иной) и тестировали всласть Строку эту набирали вручную.
А вот теперь представь, что этот клиент (C) — лишь часть клиента, а надклиент (SC) эту строку как-то сооружает и этому C передает. Так вот, эта строка и будет АПИ этого C! У C есть АПИ для SC, и он заключается в текстовой строке! Мы такое не сделали, просто потому, что не надо было. А вот сейчас я как раз такого SC и написал, заказчик его тестирует. Но это уже другая задача.
Это не сферический конь в вакууме, а часть проекта, работающего на сотнях компьютеров уже 5-6 лет.
PD>>О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ?
ГВ>Боже мой! На этот вопрос давать "общий" ответ нельзя по определению. Всё решается на месте.
+1
ГВ>Павел, не ведись ты на общую вакханалию. Приложения всегда были и будут именно "просто" приложениями.
+1. А я что, не это же говорю ?
ГВ>Значится так... Linux народился на свет в 1991. Windows NT обрела папочку в 1988:
ГВ>Иными словами, аргументы из серии "Linux логичнее, чем Windows и Windows его боится и боялся отродясь" отправляются в лес жарить шашлык.
Гена, ты что говоришь ? Я разве сравнивал логичность Windows NT и Unix ? Мне только не хватало на эту тему выступить . Я сравнивал Unix и Windows 9x, вот и все.
>Более чем уверен, что на момент выпуска NT (см. также материалы по теме OS/2) её разработчики про Linux, может, и знали чего, но так... Мало ли курьёзов в IT? Студенты, они такие — всё время вселенную потрясти пытаются, ну и пущай себе пытаются.
Да при чем тут Линукс ? Я просто хотел сказать, что продолжай они тупиковую 9x и не начни NT, их бы в конечном счете кто-нибудь съел. Не Линукс, так кто-то иной.
ГВ>С другой стороны, DOS, в принципе, это не более, чем монитор прерываний, а не операционная система. Отсюда мораль: она не могла стать ни современной операционной системой, ни какой бы то ни было существенной ОС вообще. Вся причина её успеха в том, что MS вовремя подсуетилась с заказом от IBM. Более того, согласись, забавно, что "современная ОС" по каким-то мистическим причинам недалеко ушла от ОС 70-х. Я имею в виду Unix. Тогда как куда как более моладая DOS уже предана повсеместному порицанию.
Ну тут я не со всем соглашусь. DOS все же действительно не имела многого из того. что ОС должна иметь, да ты и сам с этим согласен. Так что их сравнивать некорректно.
ГВ>Павел, да плюнь ты вообще на "классы" в частности и на "ООП" вообще. Чем дальше в лес, тем надёжнее я, например, прихожу к выводу, что "объектная ориентация" это очень большая подколка. Попросту говоря — тупиковая ветвь развития.
Ох, не знаю... Может быть.
PD>>Internet(XML request) PD>>а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.
PD>>Но я уже слышу топот копыт. Ко мне стремительно приближается сферический конь в вакууме и я начинаю ощущать вокруг себя ауру безвоздушного пространства. Так что развивать это направление не буду.
PD>>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?
ГВ>Вот честно, не догадался. Ослабел на догадки после разбора и многократного переанализа.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>По мелочам отвечу. С чем согласен — просто опустил.
Угу.
PD>>>То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры.
ГВ>>Болт! Сайт в данном случае ничего не экспонирует. Окромя допустимых аргуметов "type" и "color".
PD>Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект. Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ? Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?
Да, я считаю, что аналогия не совсем корректна. Это существенный вопрос, возьму таймаут где-то на сутки. Об остальном — ниже.
>>Речи о ынутренней структуре тут и быть не может.
PD>Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ? product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.
Ошибочна тут исходная посылка — представление сайта в виде набора агрегатов и приклеивание к этому представлению поисковых запросов.
ГВ>>Погоди. Не надо натягивать презерватив на покрышку. Это и не класс, и не методы. Это всего лишь поисковые запросы.
PD>Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй.
Тема N2 для таймаута. С ООП вообще всё неоднозначно.
PD>Я думаю, ты понимаешь, что я не предлагаю садиться и эти классы писать. Это только модель для рассуждений. Но если она неверна — объясни, почему.
Да, это я понимаю.
>>Именно так к ним и следует подходить. Они по определению не претендуют на то, что их результат окажется стабильным в долговременном представлении.
PD>И что ? А для обычных, классических функций всегда гарантировано сохранение результата во времени ? Не говоря уж о рандомах, но возьми, к примеру, алгоритмы оптимизации. Изменили метод оптимизации — получили малость другой результат. Я уж не говорю, скажем, о функциях вывода на печать — тут очень многое может измениться.
PD>>>Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели. ГВ>>Ха! Ну-ка, ну-ка, спецификацию модели в студию! Понимаешь, что имею в виду? PD>Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!
Ни в коем случае не собираюсь этого доказывать. Они не расставляют, а следовательно и не учитывают приоритеты параметров запросов. Здесь вопрос именно в том, на какую модель мы хотим натянуть описание запросов.
ГВ>>Э-э-э, батенька! Так "произвольного" или "для данной цели"?
PD>Не пойдет. Именно произвольного (т.е не обязательно броузера, а что захотим, то и напишем, и какими средствами захотим , такими и напишем, и будет он десктопным или нет — как захотим), но для данной цели. [...] Вот и все, что я хотел здесь сказать.
O'K, понял.
PD>>>Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет ГВ>>Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API. PD>WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.
Я думаю, что проще предполагать, что ссылка на .aspx — это ссылка на элемент второстепенной структуры. В прочем, это тема N3 для того же таймаута.
ГВ>>Не совсем так. Ты постоянно, как я уже говорил, пытаешься натянуть презерватив на покрышкку, то есть расширить значение терминов до невероятных ширшот (или — широтей). Это неправильно. API — это интерфейс прикладных программ. PD>Можешь считать, что я расширяю это понятие до невероятных широт, если хочешь. То, что АПИ — интерефйс программ (и не обязательно прикладных) — это верно, но утверждать, что этот интерфейс должен состоять из описаний методов, типов и т.д — не согласен. Он может, вообще говоря, быть любым.
Ладно, пока примем это допущение. Я просто хотел указать на то, что перетасовка семантики терминов может привести к нежелательным результатам.
PD>>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных. ГВ>>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся! PD>Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ?
Нет, разумеется. Просто это и в самом деле очень важно: упрощения должны быть корректными.
PD>>>Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.
ГВ>>Стойка обретает суровую стабильность...
PD>Зря ты эту стойку принял. Такое моделирование совершенно обычно в научных исследованиях. Допустим, что волновая функция молекулы есть суперпозиция волновых функций атомов. Простите, а с чего это вы такое допустили, из каких принципов волновой механики это следует ? Да ни из каких, но по ряду соображений можно предположить, что межатомные взаимодействия — эффект второго порядка. А поэтому упростим модель и посмотрим, что мы от нее можем получить. И получают ведь!
Совершенно согласен про эффект второго порядка. Не согласен с тем, что интернет можно рассматривать как иерархическую БД. Скорее, тут сетевая модель, да и то — если мы говорим только о поиске. Google, если уж продолжать начатую тобой аналогию, пытается стать корнем дерева поисковых запросов. Но ведь ими функциональность Сети не ограничивается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WFrag, Вы писали:
WF>Почему это неизвестно куда? По вполне известному адресу(-ам).
Я отправляю запрос на разрешение имени — получить IP. Я не знаю, куда он пойдет. То, что он пойдет на мой DNS сервер — роли не играет, это константа, я всегда на один и тот же адрес посылаю. А дальше пусть Интернет (точнее, распредленная БД DNS) разбирается.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Более чем уверен, что на момент выпуска NT (см. также материалы по теме OS/2) её разработчики про Linux, может, и знали чего, но так... Мало ли курьёзов в IT? Студенты, они такие — всё время вселенную потрясти пытаются, ну и пущай себе пытаются.
PD>Да при чем тут Линукс ? Я просто хотел сказать, что продолжай они тупиковую 9x и не начни NT, их бы в конечном счете кто-нибудь съел. Не Линукс, так кто-то иной.
А... Ну тады — ой. Просто ты иной раз так формулируешь, что главную посылку приходится вычислять.
PD>>>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?
ГВ>>Вот честно, не догадался. Ослабел на догадки после разбора и многократного переанализа. PD>DNS. Запрос в Интернет вообще. Неизвестно куда.
А в чём тут аналогия с твоей моделью? По-моему, самая, что ни на есть обычная база данных, относительно которой клиенты не строят никаких дополнительных предположений. Сиволическое имя -> точный адрес, да и всё.
Timeout — on
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
