Здравствуйте, Sinclair, Вы писали:
S>Так что параллелей с твоим случаем я не вижу.
А я вижу:
1985й год. Молодой Павел Дворкин узнает о новом языке "С". (заметим, что изобретен он уже 15 лет как и достаточно прилично распространен в мире уже 10 лет и уже 5 лет как появился созданный на его основе конкурент С++). Тем не менее Павел, прочитав книжку, сразу же выдает вердикт, что язык никуда не годен, то, что он предлагает легко сделть и по старинке на Фортране. И, главное, нет никакой глобальной и революционной идеи. Фигня, в общем. Однако, через 3 года, он достает эту же книгу и осознает, что язык-то действительно полезен и очень практичен и вообще рулез.
2008й год. Уже не такой молодой Павел Дворкин поднимает тему о веб-приложениях, которые он немного поизучал (и даже поразрабатывал) и пришел к выводу, что какие-то они не очень и протоколы там какие-то так себе. (заметим, что HTTP существует уже лет 15, и сами веб-приложения уже сильно распространены лет 7). И выдает вердикт, что это дело никуда не годится, а в все то же самое легко разработать и по старинке, на десктопе на С. Вот если бы была какая-то действительно серьезная революционная идея... А так — фигня в общем.
Так вот, о параллелях — есть вероятность, что года через 3 эту тему можно будет обсудить более конструктивно....
То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры. Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.
Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели. Меня интересует в первую очередь слон, а уж потом розовый. Если розового слона не будет, я готов и другим (может быть) удовлетвориться, но стихи о розовом небе мне не нужны. Здесь не AND и не OR, здесь иерархия. Это же касается поиска.
Результат этого вызова отсылается в броузер. По существу этот результат есть смесь того, что может анализироваться только с помощью естественного интеллекта (или пишите анализатор текста на естественном языке) и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером). Ввиду отсутствия четких правил и наличия различных клиентов под разными ОС этот код неизбежно вынужден ограничиться неким минимумом возможностей, которые можно использовать на клиенте. Тем не менее удается написать такой код, который в состоянии нарушить корректную работу клиента, поэтому клиент вынужден принимать меры по блокировке части этого кода, что, впрочем, плохо удается, так что в итоге ОС вынуждена принимать меры по защите от самого клиента (Vista, выполнение IE под юзеровской УЗ).
Если рассмотреть web-сервисы, то тут картина уже несколько иная. Документированы списки методов и их параметры, документирован результат. Отсюда возможность вызывать эти web-сервисы не только из стандартного клиента (броузера), но и из произвольного для данной цели написанного клиента. Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет
А теперь рассмотрим SQL-сервер. Это тоже сервер , но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов
Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.
А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных. Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.
А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов. При этом сайт а)полностью скрывает от внешнего мира свою структуру, б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.
Так что вызов сайта в этой модели выглядит так
com.a(XML request)
для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно. 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
Вот, собственно, зачем мне тут понадобился XML. Собственно, мне не XML нужен, мне язык иерархических запросов нужен, и мне показалось, что XML для этого подходит. Я за XML стоять горой не буду, мне, в общем, все равно, лишь бы можно было запрос сформировать.
О протоколе. Это действительно маловажно. Если оставаться в рамках XML, то можно прекрасно обойтись без HTTP, Заменив его на XMLTP . Если же считать HTTP частью транспорта, то можно и с ним. Иными словами, вполне приемлема схема с протоколом прикладного уровня XML, работающим поверх транспортного протокола HTTP/TCP/IP.
О семантике. Она, как всегда, за сценой и плохо формализуема. Ты писал
>что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.
Да, конечно, без согласования толку не будет, но в этом согласовании могут участвовать клиент и сервер. Возьмем опять SQL сервер. Если мы ничего не знаем о БД, то мы даже SELECT * FROM сделать не можем, поскольку не знаем FROM что. Но SQL сервер готов нам помочь, вернув свою схему, для этого надо только знать, где он находится, больше ничего. Схема определяет предметную область (об этом ниже) и структуру базы (сервера), и ее анализ, вообще говоря, позволить делать вполне осмысленные запросы. Тут есть и роль сервера, и роль клиента. Сервер вполне может представить эту схему не в виде DDL, а в чем-то более интеллектуальном, вроде объектного графа. Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.
За сценой пока что остался смысл всего этого. Тут я возвращаюсь к твоему примеру с tiff
ГВ>1. Что в природе вообще существует некий эдакий штук под названием .tiff-формат, котрый обрабатывается вон той подпрограммой. ГВ>2. Что вроде бы, он должен быть картинкой. ГВ>3. Что если он встретит узел с названием <picture> (условно), у которого есть атрибут с названием "url", то этот самый "url" является не чем-нибудь, а именно URL в соответсвии с подобающими спецификациями (иначе это будет ошибка) ГВ>4. Что вычисленный шагом ранее URL содержит некоторый такой известный браузеру штукЪ под названием "расширение файла", ГВ>5. ...или, что в том же узле picture посредством другого атрибута указан "content/type", сведения из которого отменяют полученные на ш. 4, ГВ>6. Что загрузив некие невнятные данные с этого URL, опираясь на сведения о content/type можно эти данные затолкнуть вон той вот подпрограмме, которой нужно кроме того отдать всякие графические контексты и прочую требуху — нечто, наверное, нарисуется на экране пользователя.
Все так. Кстати, это же верно и для запросов. Ну подадим мы на запросе
type=elephant&color=rose.
Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.
Но в действительности все далеко не так плохо обстоит. Гарантии , конечно, нет, но, положа руку на сердце — тебе часто встречались .tiff файлы, содержащие не картинку ? Может, и встречались, но вряд ли часто. Идея расширений на удивление хорошо работает. Я сам брошу камень в того, кто предложит по расширениям однозначно судить о содержании файла, но ведь в 99.9% случаев это верно! По существу расширения — это некий лексикон, вошедший в большинство современных естественных языков (не всех, я совсем не уверен, к примеру, насчет LANGUAGE_MUMBO_JUMBO . А и в пределах самого языка «слон» — это, как правило, все же животное известного вида с хоботом, а не что-то иное. Это не работает на 100%, несомненно, но, в общем, работает. А делая запрос к Гуглу, мы это как-то учитываем ? Точнее, Гугл как-то разбирается в том, что , найдя на странице розового слона, надо проанализировать текст и на основе этого анализа отнести страницу к тем, которые надо выдавать на запрос «вечеринка выпивка» ? Вряд ли
О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ? Ответ прост — если речь идет о вводе данных (стандартном действии), то для этого и надо использовать стандартный класс окон (диалоги), если же речь идет о действиях явно нестандартного вида, то надо создавать свое окно, тем более, что в диалоговых окнах некоторые возможности, легко и просто реализуемые в своих окнах, реализуются с трудом или вообще не реализуются (например, перехват сообщений в петле модального диалога реализуется только с вывертом, именуемым хуком, в то время как в своем окне он реализуется элементарно). То же и здесь. Если речь идет о вводе данных и отсылке их на сервер — незачем велосипед изобретать. Если же мы собираемся писать PhotoShop для сети , то работать он будет на клиенте, а для связи с сервером использовать некую часть, реализуемую с помощью стандартных средств (окна типа диалога, будет это окно частью иного процесса или же просто окном диалоговых интернет-окон — это не самое важное, хотя я склоняюсь ко второму). Так что клиент должен заниматься своим делом, а сервер своим. А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.
И последнее. Сколько это будет стоить ? Сумасшедшие деньги. Без всякого сомнения. Будет ли это реализовано ? Не знаю. Знаю одно — нынешняя модель явным образом начинает переживать самое себя. Ее развитие, в силу заложенного в нее подхода, не соответсвующего объектной модели, ведет к тому, что в ней то и дело принимаются решения ad hoc, что приводит к появлению в ней заплат, а потом заплат на заплате. Раньше или позже сложность и внутренняя нелогичность этой модели превысит определенный порог, после чего появится некая белая мышь и погубит этих динозавров. Вполне возможно, что эта мышь будет совсем не похожа на то, что я описал.
В заключение один простой пример. В 1990 году появляется Windows 3.0, в 1995 — Windows 95. Обе приняты на ура. В обе MS вложила сумасшедшие деньги. А теперь представь себе, что в эйфории от успеха этих систем в MS приняли бы решение продолжать их развитие и нового не создавать. Это развитие, безусловно, было бы успешным (оно и было, кто назовет Windows 98 и ME провалом ?). В общем, примерно так до 2000 года все шло бы прекрасно, несмотря на то, что внутренняя структура Windows 9x чудовищна и представляет собой заплату на заплате. А вот после 2000 года (а может, 2005, а может, и 2010) все быстро пошло бы вниз. Потому что растет и развивается конкурент — Линукс. У него с этим самым usability проблемы на проблеме, но внутренняя его структура разумна и корректна. Так что не начни MS разработку линии NT (и кстати, пригласив для этого специалиста со стороны, видимо, опасаясь того, что свои специалисты могу Windows 9x Enhanced соорудить ) — я думаю, позиции линуксоидов были бы сейчас на порядок более обоснованными, чем мы имеем в действительности. Usability в Линуксе, если взяться как следует, привести в божеский вид можно. Из ядра Windows 9x сделать нормальное ядро современной ОС нельзя.
И уж совсем в заключение. Заменив вызов
com.a.html.product(type=elephant,color=rose)
на
com.a(XML request)
можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид
Internet(XML request)
а уж сам класс Internet пусть и решает, куда и как этот запрос перенаправить.
Но я уже слышу топот копыт. Ко мне стремительно приближается сферический конь в вакууме и я начинаю ощущать вокруг себя ауру безвоздушного пространства. Так что развивать это направление не буду.
Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно. 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
А в чём разница? Почему ты считаешь, что вместе с кодом 404 нельзя отправить нормальный ответ, возможно, с подсказками?
PD>Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, Sinclair, Вы писали:
S>>Так что параллелей с твоим случаем я не вижу.
F>А я вижу: F>1985й год. Молодой Павел Дворкин узнает о новом языке "С". (заметим, что изобретен он уже 15 лет как и достаточно прилично распространен в мире уже 10 лет и уже 5 лет как появился созданный на его основе конкурент С++).
Жаль, нет движения во времени. Отправить бы тебя в 1980 , дать колоду перфокарт...
Отвечу где-то за полночь по твоему времени. Кратко, как понимаешь, тут не получается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mamut, Вы писали:
M>Уверен Например, никто из участников этого форума не сможет открыть эт ссылку в Янусе, если ее пришлют по аське. А ъотелось бы
И все же я думаю, что кликать на нем не стоит. Он может и обидеться
ГВ>>Рассуждение совершенно "в сторону", но тем не менее. ГВ>>Электронная почта (если иметь в виду почтовые программы для человека) — это настолько простенькая задача сама по себе, что её можно "положить" на всё, что душе угодно. Функционалу-то, раз-два и обчёлся. S>Ага. Поэтому меня неизменно удивляет тот факт, что уже двадцать с лишним лет прогрессивное человечество не может сделать приличного почтового клиента.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Mamut, Вы писали:
M>>Причем функциональности, подобной Flickr Worldmap там нет и не предвидится.
AVK>Я что то проглядел может, но geotagged картинки с Panoramino в гуглоземе есть уже больше года, причем покрытие фотками поплотнее будет.
PD>можно и дальше пойти. А зачем, здесь, собственно говоря, 'a' присутсвует ? И com зачем ? Это ведь тоже раскрытие внутренней структуры класса. Если пойти дальше, то запрос должен иметь вид
PD>Internet(XML request)
Кстати. Интернет в целом, конечно, никакое не дерево, но элементы "деревянной" структуры в нем есть. В терминах рассматриваемого подхода деятельность Google за последние годы в плане поиска представляет собой не что иное, как попытку создать в Интернете это дерево, утвердив себя в качестве его корня
Здравствуйте, Pavel Dvorkin, Вы писали: PD>http://a.com/product.html?type=elephant&color=rose PD>Это фактически PD>com.a.html.product(type=elephant,color=rose)
Совершенно верно. PD>То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры.
У сайта нет классов и методов. У сайта есть ресурсы, внутренняя структура которых экспонируется через слабо определенный навигационный интерфейс.
Характерные примеры экспонирования внутренней структуры сайта:
1. Прямые ссылки (<link>, <a>), которые нативно поддерживаются в html/xhtml, а также являются типичными для XML-based форматов вроде ATOM или RSS. Принципиальная проблема — отсутствие возможности описать бесконечное пространство целевых адресов.
2. Ссылки на семейства URL. Например: формы в html/xhtml, URL Templates запланированные в XHTML 5.0 и встроенные в OpenSearch.
PD>Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.
PD>Замечу, кстати, что в вызове этого метода параметры равноправны, что не соответсвует, вообще говоря, требуемой модели. Меня интересует в первую очередь слон, а уж потом розовый. Если розового слона не будет, я готов и другим (может быть) удовлетвориться, но стихи о розовом небе мне не нужны. Здесь не AND и не OR, здесь иерархия.
Значит, автор сервиса неудачно выбрал структуру URL.
По традиции, иерархические параметры входят в Path:
http://a.com/products/elephant/rose.html
PD>Это же касается поиска.
PD>Результат этого вызова отсылается в броузер. По существу этот результат есть смесь того, что может анализироваться только с помощью естественного интеллекта (или пишите анализатор текста на естественном языке) и callback кода , который в свою очередь состоит из кода для представления этого результата плюс код по управлению самим клиентом (броузером). Ввиду отсутствия четких правил и наличия различных клиентов под разными ОС этот код неизбежно вынужден ограничиться неким минимумом возможностей, которые можно использовать на клиенте. Тем не менее удается написать такой код, который в состоянии нарушить корректную работу клиента, поэтому клиент вынужден принимать меры по блокировке части этого кода, что, впрочем, плохо удается, так что в итоге ОС вынуждена принимать меры по защите от самого клиента (Vista, выполнение IE под юзеровской УЗ).
Ну, по какой-то причине браузер справляется с обработкой этого результата безо всякой помощи естественного интеллекта.
PD>Если рассмотреть web-сервисы, то тут картина уже несколько иная. Документированы списки методов и их параметры, документирован результат. Отсюда возможность вызывать эти web-сервисы не только из стандартного клиента (броузера), но и из произвольного для данной цели написанного клиента. Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет
Гарантий по сохранности интерфейса нет вообще нигде. Гарантии — не технический аспект, а административный. Точка.
Техническим аспектом может быть облегчение поддержки версионности интерфейсов.
В частности, поддержка discovery версий протоколов и negotiation по поводу версии.
PD>А теперь рассмотрим SQL-сервер. Это тоже сервер , но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов
Это заблуждение. Современный SQL-cервер экспонирует свою внутреннюю структуру и список "методов" только в путь.
Опять же, SQL сервер нужно трактовать как некоторый набор ресурсов (записей), объединенных в таблицы и view. Набор "методов" жестко вшит в стандарт SQL: SELECT/INSERT/UPDATE/DELETE.
Как только ты узнал, что есть таблица с именем Orders и колонками ID, CustomerID, Amount, ты сразу можешь делать
select CustomerID, sum(Amount) as TotalAmount from Orders group by CustomerID order by 2 desc
PD>Но совершенно ясно, что на этом пути мы ничего хорошего не получим. Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.
Так что API SQL-сервера — это набор таблиц, view, и хранимых процедур, которые он способен выполнять.
PD>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных. Я вовсе не забыл про внутренние ссылки (внешние меня сейчас не интересуют) , делающие его в действительности сетевой БД), но остовное дерево в нем есть В конце концов архитектура сайта чаще всего имеет форму «почти дерева» — home page, основное меню и т.д. Хотя , конечно, это определенное упрощение.
PD>А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов.
Совершенно верно. Так и делается; синтаксис XPath намеренно был сделан похожим на синтаксис URL.
PD>При этом сайт а)полностью скрывает от внешнего мира свою структуру,
Не очень понятно, что такое "своя структура". Есть две интерпретации понятия "структура сайта":
1. Направленный граф, который описывает страницы, входящие в сайт, и ссылки между ними. Так видят сайт поисковики.
2. Дерево, которое описывает взаимоотношения URL, независимо от фактических ссылок. Например, страница http://a.com/products/elephant/ будет считаться дочерней для http://a.com/products/, независимо от того, кто на кого ссылается. Так видит сайт человек, который пытается разобрать URL по частям.
Ни та, ни другая структура не имеют никакого отношения к тому, что творится "внутри" сервера.
PD>б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.
Запросы реализуются той формой, которую заложил в серверную часть ее разработчик.
There are three basic rules for URI design, born of collective experience:
1. Use path variables to encode hierarchy: /parent/child
2. Put punctuation characters in path variables to avoid implying hierarchy where
none exists: /parent/child1;child2
3. Use query variables to imply inputs into an algorithm, for
example: /search?q=jellyfish&start=20
PD>Так что вызов сайта в этой модели выглядит так PD>com.a(XML request)
Что гораздо хуже, по очевидным причинам PD>для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно.
Структура сайта — это то, по чему ты делаешь запрос. Если она изменилась, то твой XPath или что ты там придумал в качестве "некоторой иерархичной формы" ничего не найдет.
PD> 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
Вполне нормальный ответ — это 404. По стандарту, веб сервер должен дать в теле такого ответа те самые подсказки. PD>Вот, собственно, зачем мне тут понадобился XML. Собственно, мне не XML нужен, мне язык иерархических запросов нужен, и мне показалось, что XML для этого подходит. Я за XML стоять горой не буду, мне, в общем, все равно, лишь бы можно было запрос сформировать.
PD>О протоколе. Это действительно маловажно. Если оставаться в рамках XML, то можно прекрасно обойтись без HTTP, Заменив его на XMLTP . Обойтись — можно; прекрасно — нет.
В отличие от самописанного протокола, HTTP поддерживает массу фич, даже если не рассматривать наличие готовых клиентов на всех платформах в качестве преимущества.
В частности, я в пятьсот седьмой раз напоминаю, что HTTP поддерживает кэширование и компрессию.
PD>Если же считать HTTP частью транспорта, то можно и с ним. Иными словами, вполне приемлема схема с протоколом прикладного уровня XML, работающим поверх транспортного протокола HTTP/TCP/IP.
PD>О семантике. Она, как всегда, за сценой и плохо формализуема. Ты писал
>>что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.
PD>Да, конечно, без согласования толку не будет, но в этом согласовании могут участвовать клиент и сервер. Возьмем опять SQL сервер. Если мы ничего не знаем о БД, то мы даже SELECT * FROM сделать не можем, поскольку не знаем FROM что. Но SQL сервер готов нам помочь, вернув свою схему, для этого надо только знать, где он находится, больше ничего. Схема определяет предметную область (об этом ниже) и структуру базы (сервера), и ее анализ, вообще говоря, позволить делать вполне осмысленные запросы. Тут есть и роль сервера, и роль клиента. Сервер вполне может представить эту схему не в виде DDL, а в чем-то более интеллектуальном, вроде объектного графа. Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.
Никаких проблем тут нет. WWW сервер уже представляет свою структуру, и есть несколько стандартов на эту тему.
PD>За сценой пока что остался смысл всего этого. Тут я возвращаюсь к твоему примеру с tiff
PD>type=elephant&color=rose.
PD>Где гарантия, что на каком-то молодежном сленге розовый слон не означает вечеринку с выпивкой ? Нет такой гарантии. И нет гарантии, что файл .tiff содержит действительно байты, представляющие собой картинку.
RTFM Content-Type.
PD>Но в действительности все далеко не так плохо обстоит. Гарантии , конечно, нет, но, положа руку на сердце — тебе часто встречались .tiff файлы, содержащие не картинку ?
Редко. Зато .php, возвращающие картинку — cплошь и рядом. PD> Может, и встречались, но вряд ли часто. Идея расширений на удивление хорошо работает.
На удивление плохо она работает. Курить контент-тайп на предмет graceful degradation. Например, в сторону application/atom+xml, или хотя бы image/tiff. Какое расширение позволит клиенту сделать какие-либо выводы относительно содержимого, даже если само оно клиенту неизвестно?
PD>Я сам брошу камень в того, кто предложит по расширениям однозначно судить о содержании файла, но ведь в 99.9% случаев это верно!
Это заблуждение. PD>По существу расширения — это некий лексикон, вошедший в большинство современных естественных языков (не всех, я совсем не уверен, к примеру, насчет LANGUAGE_MUMBO_JUMBO . А и в пределах самого языка «слон» — это, как правило, все же животное известного вида с хоботом, а не что-то иное. Это не работает на 100%, несомненно, но, в общем, работает. А делая запрос к Гуглу, мы это как-то учитываем ? Точнее, Гугл как-то разбирается в том, что , найдя на странице розового слона, надо проанализировать текст и на основе этого анализа отнести страницу к тем, которые надо выдавать на запрос «вечеринка выпивка» ? Вряд ли
Как раз гугл во всем очень хорошо разбирается в том, что он читает. К примеру, он умеет отличать plain text от html независимо от расширения.
PD>О том, где должен код выполняться — на клиенте или сервере. Тут ответ довольно-таки банален. Вот представь себе классическое Win32 десктопное приложение. Как в нем надо работу организовать — писать свой класс окна или воспользоваться стандартным классом диалоговых окон ? Ответ прост — если речь идет о вводе данных (стандартном действии), то для этого и надо использовать стандартный класс окон (диалоги)
Буэээ. PD>, если же речь идет о действиях явно нестандартного вида, то надо создавать свое окно, тем более, что в диалоговых окнах некоторые возможности, легко и просто реализуемые в своих окнах, реализуются с трудом или вообще не реализуются (например, перехват сообщений в петле модального диалога реализуется только с вывертом, именуемым хуком, в то время как в своем окне он реализуется элементарно). То же и здесь. Если речь идет о вводе данных и отсылке их на сервер — незачем велосипед изобретать. Если же мы собираемся писать PhotoShop для сети , то работать он будет на клиенте, а для связи с сервером использовать некую часть, реализуемую с помощью стандартных средств (окна типа диалога, будет это окно частью иного процесса или же просто окном диалоговых интернет-окон — это не самое важное, хотя я склоняюсь ко второму). Так что клиент должен заниматься своим делом, а сервер своим. А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.
PD>И последнее. Сколько это будет стоить ? Сумасшедшие деньги. Без всякого сомнения. Будет ли это реализовано ? Не знаю. Знаю одно — нынешняя модель явным образом начинает переживать самое себя. Ее развитие, в силу заложенного в нее подхода, не соответсвующего объектной модели, ведет к тому, что в ней то и дело принимаются решения ad hoc, что приводит к появлению в ней заплат, а потом заплат на заплате. Раньше или позже сложность и внутренняя нелогичность этой модели превысит определенный порог, после чего появится некая белая мышь и погубит этих динозавров. Вполне возможно, что эта мышь будет совсем не похожа на то, что я описал.
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 пусть и решает, куда и как этот запрос перенаправить.
Угу. Я прямо-таки вижу как из интернета появляется Мистер Мускул и говорит "желаемое исполнено". Только вместо XML Request выступает WebRequest. Остальное — на 100% правда.
PD>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ?
Надо полагать, речь идет о DNS.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>>Хотя... По крайней мере один сервис, работающий по этой модели, существует уже сейчас. Правда, без XML, и весьма простой. Это опять-таки запрос к некоторой БД, но весьма своеобразно устроенной. Догадался, что я имею в виду ? S>Надо полагать, речь идет о DNS.
Вот здесь ты прав.
Все остальное ты так и не понял. Потому что ты просто не умеешь абстрагироваться от того, что ты знаешь.
S>У сайта нет классов и методов. У сайта есть ресурсы, внутренняя структура которых экспонируется через слабо определенный навигационный интерфейс
Будто я без тебя не понимаю, что есть у сайта или чего нет. Я о некоторой модели говорю (сайт с точки зрения ООП), а мне в ответ — да нет там класса, есть только ресурсы с навигацией... И как там кеширование будет ?
PD>То есть сейчас мы имеем дело с вызовом метода этого сайта, при том, что сайт экспонирует свою внутреннюю структуру, не давая при этом никакой гарантии, что сохранятся в будущем его внутренние классы, их методы и их параметры. Мы фактически сохраняем (в Favourites, к примеру, или Google это делает) указатели на удачные вызовы методов этого класса, в надежде на то, что и в будущем эти вызовы сработают. Как правило, так и бывает, но не всегда — может исчезнуть внутренний экземпляр класса, его метод или измениться список параметров, отсюда 404. Кроме того, нам неизвестен ни список полей, ни список методов, ни список параметров.
Как это изменится для десктоп приожения, которое с этими же сервисами будет работать?
PD>А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов.
Почему и откуда это следует?
PD>При этом сайт а)полностью скрывает от внешнего мира свою структуру, б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.
PD>для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно. 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
PD>Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.
WSDL, например. Люьой вменяемый веб-сервис дает описание своего АПИ
> А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.
Не пойдет. Тогда нам нужно сначала поставить некую uber-ОС на все компьютеры
А что произойдет, если я пойду в интернет-кафе, в котором этой программы не установлено, а злой админ не позволяет ее ставить?
В этом плане гораздо блее интересен подход Эппл и ее приложениями для айфона в контексте Сафари. К сожалению, на данный момент будущего у такого мало из=за несовершенства браузеров в том числе.
Если приложение сможет запуститься само в контексте какой-нибудь песочницы (как сейчас — в браузере), то только тогда имеет смысл говорить о "просто приложениях", имхо
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 пусть и решает, куда и как этот запрос перенаправить.
И какая разница? Мы все равно сообщаем, что мы хотим и от кого мы хотим. Только переносим это из строки запроса в передаваемые данные. Шило на мыло, в общем.
Здравствуйте, Pavel Dvorkin, Вы писали: S>>Надо полагать, речь идет о DNS. PD>Вот здесь ты прав.
PD>Все остальное ты так и не понял. Потому что ты просто не умеешь абстрагироваться от того, что ты знаешь.
Умею. А еще я умею рассматривать одну и ту же вещь с разных точек зрения.
PD>Будто я без тебя не понимаю, что есть у сайта или чего нет. Я о некоторой модели говорю (сайт с точки зрения ООП), а мне в ответ — да нет там класса, есть только ресурсы с навигацией... И как там кеширование будет ?
Совершенно верно. Рассматривать интернет с точки зрения ООП не очень конструктивно. ООП вообще в распределенном мире работает очень плохо. Это медицинский факт.
Конструктивнее рассматривать интернет с точки зрения SQL, но тоже не очень хорошо — потому, что SQL подразумевает такие операции, выполнение которых в интернете заведомо приведет к чудовищным затратам вычислительных ресурсов.
Поэтому модель ресурсно-ориентированной сети в настоящее время немеряно рулит. Не потому, что она есмь единственное, что я могу воспринять своим убогим мозгом, а потому, что она хорошо соответствует техническим и психологическим реалиям.
А ты вместо того, чтобы понять причины этого руления, предпочитаешь пытаться обвинить меня в неспособности от чего-то там абстрагироваться. PD>Продолжать дискуссию нет смысла.
Ну почему же. Все остальные участники вполне себе извлекают пользу из нашей дуэли.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>Как это изменится для десктоп приожения, которое с этими же сервисами будет работать?
Никак. Я это уже не обсуждаю.
PD>>А если сайт есть иерархическая БД, то и АПИ этого сайта должен представлять собой вызов единственного метода ExecXML, которому передется некий запрос на языке иерархических запросов.
M>Почему и откуда это следует?
Это моя точка зрения, которую я высказываю и обосновываю.
PD>>При этом сайт а)полностью скрывает от внешнего мира свою структуру, б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.
M>Что за тысячи ссылок?
Ну я же объяснял, чем отличается иерархический запрос.
PD>>для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно. 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
M>http://php.net/some_func
M>404 с подсказками
Да, конечно, но не в этом же дело.
PD>>Аналогично и www-сервер мог бы представить свою структуру для того, чтобы запросы к нему на АПИ были более или менее осмысленны. Хотя да, тут проблем много.
M>WSDL, например. Люьой вменяемый веб-сервис дает описание своего АПИ
Дает.
>> А в результате у нас, как я не раз уже писал, будут не десктопные или web-приложения, а просто приложения. С той или иной интернет- компонентой.
M>Не пойдет. Тогда нам нужно сначала поставить некую uber-ОС на все компьютеры
Это сейчас за пределами обсуждения.
M>А что произойдет, если я пойду в интернет-кафе, в котором этой программы не установлено, а злой админ не позволяет ее ставить?
M>И какая разница? Мы все равно сообщаем, что мы хотим и от кого мы хотим.
В данном случае только "что" и не указываем "от кого". От Интернета в целом. Речь идет о DNS — запросе.
Не обижайся, но ты просто ИМХО не понял, о чем идет речь. Я уже не обсуждаю сейчас ни клиента, ни сервера, меня сейчас только запрос и ответ как таковой интересуют, точнее, форматы их и соответствие этих форматов объектной модели сайта и клиента, а также распределение функций между ними. Все остальное за пределами обсуждения.
PD>>>При этом сайт а)полностью скрывает от внешнего мира свою структуру, б) запросы к сайту реализуются не простой булевской формой, как сейчас в командной строке или поиске, а некоторой иерархичной формой, что позволяет его сделать гораздо более конкретным и тем самым избавиться от тысяч ссылок в ответ на запрос.
M>>Что за тысячи ссылок?
PD>Выдаваемых Гуглом, к примеру. Или поиском на этом же сайте
Гугл и этот сайт их так выдает, потому что человек, сидящий за компьютером, должен их увидеть в какой-то форме.
Насколько я помню, тот же Гугл вполне способен выдавать результаты поиска (и не только) вполне себе в машиночитаемой форме (в их конкретном случае в XML)
M>>А такой запрос не устроит: http://superstore/?item=elephant&preference=pink ? Какие преимущества гипотетического запроса?
PD>Ну я же объяснял, чем отличается иерархический запрос.
Ну и в моем запросе я говорю: хочу слона (item=elephant), предпочтительно розового (preference=pink)
А чем отличается иерархический запрос, я, честно говоря, не понял
PD>>>для всех обращений. Структура сайта скрыта, а поэтому может изменяться как угодно. 404 не может возникнуть, хотя, конечно, возможно, что на данный запрос не найдется ответа, но это будет не исключение PageNotFound, которое сейчас предлагают обрабатывать пользователю как ему вздумается, а вполне нормальный ответ, возможно, с подсказками.
M>>http://php.net/some_func
M>>404 с подсказками
PD>Да, конечно, но не в этом же дело.
А в чем же?
M>>И какая разница? Мы все равно сообщаем, что мы хотим и от кого мы хотим.
PD>В данном случае только "что" и не указываем "от кого". От Интернета в целом. Речь идет о DNS — запросе.
PD>Не обижайся, но ты просто ИМХО не понял, о чем идет речь. Я уже не обсуждаю сейчас ни клиента, ни сервера, меня сейчас только запрос и ответ как таковой интересуют, точнее, форматы их и соответствие этих форматов объектной модели сайта и клиента, а также распределение функций между ними. Все остальное за пределами обсуждения.
Здравствуйте, Mamut, Вы писали:
M>Ну и в моем запросе я говорю: хочу слона (item=elephant), предпочтительно розового (preference=pink)
M>А чем отличается иерархический запрос, я, честно говоря, не понял
Сформулируй (например, для Гугла) запрос вида
Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Хочу слона. Если будет розовый, это сразу годится. Если розового не будет, то устроит любого цвета, но только индийский (замечу, что розовый годился бы и африканский) и при этом либо весом не более тонны либо самка. Если ничего такого не найдется, вернуть любого мамонта, но только из Восточной Сибири.
Павел, ты наверное как-то не так понял идею интернета.
В ней нет никаких языков запросов. Совсем. Когда я иду по адресу http://google.com?q=pink+elephant, я получаю доступ к уникальному ресурсу.
Благодаря тому, что реальная структура интернета от меня скрыта, гугл в ответ на это возвращает некоторый специальный ресурс.
А тепер, чтобы ты не обвинял меня в том, что всё время рассказываю только про то, что уже есть (хотя, имхо, перед тем, как изобретать свой порох, крайне полезно ознакомиться с существующими вариантами), поговорим об Универсальном Языке Запросов Выразительном Абсолютно (УЯЗВА).
Я правильно понимаю, что ты бы хотел чтобы такой язык существовал и поддерживался той альтернативой веб сервисам, которую ты пытаешься изобрести?
Тот запрос, который ты привел, сводится к предикатам первого порядка над объектами из некоторой примитивной модели.
Грубо говоря, это некоторое подмножество SQL. Осталось понять, насколько широк тот класс запросов, который ты собираешься потребовать от реализации.
Забегая вперед, поясню: REST подход к веб-сервисам состоит в отказе от попытки описать всё подряд некоторым языком запросов. Если тебе хочется получить свой язык запросов — пожалуйста, реализуй его поверх существуюшего протокола. Благодаря этому нет нужды расширять протокол для того, чтобы перейти от запросов "дай мне документы, содержащие слово Dvorkin", к запросам "дай мне заправки рядом с Красной Площадью". С точки зрения математики это два совершенно разных класса запросов, которые крайне тяжело реализовать в рамках одного языка. С точки зрения веба это всего лишь определенные ресурсы, URL к которым строится по определенным правилам. Причем правила не зашиты в протоколе, а передаются на машину пользователя в рамках "самозагружаемого" клиента.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
