Я совсем не о том говорю. Разумеется XML-RPC предоставляет вам вызовы функций с конвертацией параметров элементарных типов. Только это и не задача вовсе, чтобы радоваться её решению. Задача — это интероперабельность на уровне приложений, а не на уровне транспорта.
Попробую ещё раз. Если бы мы не использовали REST'ового подхода со стандартными MIME-типами, некому блог-клиенту пришлось бы изучать наш собственный протокол, и это *big deal*. А сейчас блог-клиенту для поддержки Я.ру надо, грубо говоря, знать, с какого URL'а у нас AtomPub начинается, и как авторизация делается. Это гораздо меньше, чем поддержка отдельного протокола.
> Конечно rest хорош тем, что кроме библиотеки http вам больше ничего не нужно(ну ещё xml)
Здесь сразу два заблуждения. Во-первых, REST вообще никак не связан с XML. Во-вторых, с протоколом не предполагается работать напрямую, предполагается использовать библиотеки. Основная ценность REST'а проявляется в реализации на серверной стороне и в реализации библиотек, а не для конечных пользователей, которым, по идее, должно быть всё равно.
> XML-RPC радует своей простотой. В том же питоне посмотрите примеры — это просто песня.
Я не говорю о простоте конечного прикладного кода, я говорю об архитектуре. Любое кастомное XML-RPC сложно в освоении и поддержке, как раз потому что оно кастомно. А интеграция разных RPC-сервисов друг с другом часто совсем невозможна из-за отсутствия адресуемости ресурсов, например.
Простота конечного кода обеспечивается библиотекой прикладного уровня, независимо от того, какие запросы она в провода генерит. Никто не спорит, что с ней было бы приятней. С чем я спорю — так это с тем, что XML-RPC интерфейс заменил бы собой написание такой библиотеки руками.
Не скажу ничего конкретного, кроме того, что про OpenID мы знаем, хотим, и думаем в том направлении. Но будет ли оно, и если да, то когда — не знаю. Слишком много переменных :-)
Простите, это просто неправда. Amazon и Google — как раз одни из самых больших пропонентов REST-протоколов. Google Data — это REST'овый AtomPub, а Amazon S3 — хрестоматийный пример REST-сервиса, про который в книжках пишут.
Кстати, от SOAP-интерфейс к поиску Google отказался (http://code.google.com/apis/soapsearch/). Просто потому что на практике он не «рулит» и не «бибикает».
Вообще, то, что вы просите — это не SOAP, а просто более высокоуровневая библиотека. Повторюсь, она скорее всего напишется под ваш любимый язык, если мы правильно будем продвигать дальше платформу.
XML-RPC — это не протокол блог-платформы, а протокол вызова функций на другой машине. Он не предполагает какого-то конкретного API. Поэтому говорить, что используя XML-RPC можно получить универсального клиент для всех блог-платформ, неверно. XML-RPC тут помогает не больше, чем если бы все перечисленные вами платформы были написаны на одном языке программирования. С клиентской стороны это незначительная реализация.
Чтобы сделать универсальный блог клиент, нужен протокол application-уровня, который будет оперировать понятиями «пост», «автор», «фид», «категория» и т.д. И такой протокол есть — AtomPub (http://tools.ietf.org/html/rfc5023). И — сюрприз — именно он и используется у нас в части общения с блогом :-).
Также этот протокол используется в Blogger (http://code.google.com/apis/blogger/, Google Data — это расширенный AtomPub), WordPress (http://codex.wordpress.org/AtomPub). Кроме того, этот же протокол поддерживает такой известный блог-клиент, как Windows Live Writer: jcheng.wordpress.com/2007/10/15/how-wlw-speaks-atompub-introduction/. Я, правда, не видел глазами, насколько WLW будет работает с Я.ру через AtomPub, предполагаю, что не сразу (поскольку мы таки в бете ещё), но мы будем рады поработать над этим с серверной стороны, если кому интересно.
Другими словами, слова «с нуля» и «велосипед» применимы как раз к ad-hoc XML-RPC решениями, которые только с виду выглядят очень простыми.
Ага. Хотя прямо сейчас это скорее страшно, чем приятно :-). Потому что драфт OAuth 2.0 ещё сильно нестабильный. Мы будем стараться поспевать за изменениями.
> Хм… Несомненно, с точки зрения красивости, ваша схема отлична. Но с точки зрения готовых библиотек, через XML-RPC или WSDL было бы проще…
Использование WSDL сильно ограничило бы число клиентских платформ, поэтому это вообще не вариант. Что касается XML-RPC и REST, то поскольку они совершенно противоположны по идеологии, простота сильно зависит от того, откуда вы смотрите и какие у вас привычки. По мне, так совершенно идентичный подход REST к семантике редактирования и удаления, самоописывающиеся документы и прочие идеологические вкусности — это большой плюс.
> Ждем тогда официальную либу для этих сервисов для разных языков, как это делает гугль.
С либой всегда проще, да. Хотя я пока жду, что кто-нибудь напишет её быстрее нас :-).
Нет, не использую. Кроме IDE-все-в-одном-все-кривое и консоли-храните-все-в-голове есть и другие опции. Но в рамках комментария я про это, пожалуй, не расскажу…
> При более ли менее приличных объемах разработки тормозззззит страшно. Вешает Наутилус на долгие-долгие минуты.
+1. Еще плохо, что она с тех пор не развивается. А так как она все же много не умеет, я от нее в итоге отказался.
> и, поверьте, в консоли намного удобнее
Это примерно как объяснять пешеходу удобство АКПП. Или водителю — полезность зонта. В консоли удобнее, только если вы всю разработку делаете через нее, а если ее надо специально открывать и идти в нужную директорию только для того, чтобы сделать svn commit, то это дико неудобно.
Я плохо понял, какую вы мысль хотите донести, если честно... Но кое-что тут просто неверно, уж извините.
> Семантика нужна для всего, в том числе для отображения любым
> образом, отличным от того, что вытекает из синтаксиса.
Это, в общем, верно, за вычетом того, что из синтаксиса (HTML'а) вообще никакого отображения не вытекает.
> Всё, что браузер может сделать таким образом, это положиться на
> семантику CSS, расчитанную как раз на отображение.
CSS семнатикой не нагружен. Просто по спецификации. Если вы вещаете на элемент <span> свойство display: block, он не становится блочным семантически. Например, запихивание в него <div> не станет вдруг легальным.
> Это да, но тут, наверное, дело в том, что линки или формы — это
> специфические элементы гипертекста. ведь тоже в CSS
> не описать, как я понимаю.
CSS'у это не нужно описывать. Он предоставляет базовые возможности для оформления произвольных иерархических документов. А также определяет такое понятие, как "replaced element", про который говорится, что UA может рисовать его внутри, как считает нужным. Соответственно, UA, который знает о семантике HTML, знает, как внутри рисовать элементы форм, картинки и прочее.
(про остальное говорить не хочу, слишком обширная тема для короткого комментария)
"Немогумолчать!" (с) :-). Нельзя же так вольно обходиться с разными понятиями...
Семантика не нужна для *отображения* XML'а. И браузеры прекрасно умеют отображать XML, применяя к нему CSS. Смысл (семантика) нужен для вещей, которые находятся сверх отображения чтобы элементы "работали правильно". Браузер делает из тега <a> кликабельную ссылку, потому что знает, что у тега <a> такая семантика. Любой другой элемент любого XML- или HTML-документа тоже можно стилизовать под ссылку. Выглядеть оно будет также, но "Открыть в новом окне" браузер для нее в меню не покажет.
Откуда такая информация?
Попробую ещё раз. Если бы мы не использовали REST'ового подхода со стандартными MIME-типами, некому блог-клиенту пришлось бы изучать наш собственный протокол, и это *big deal*. А сейчас блог-клиенту для поддержки Я.ру надо, грубо говоря, знать, с какого URL'а у нас AtomPub начинается, и как авторизация делается. Это гораздо меньше, чем поддержка отдельного протокола.
Здесь сразу два заблуждения. Во-первых, REST вообще никак не связан с XML. Во-вторых, с протоколом не предполагается работать напрямую, предполагается использовать библиотеки. Основная ценность REST'а проявляется в реализации на серверной стороне и в реализации библиотек, а не для конечных пользователей, которым, по идее, должно быть всё равно.
Я не говорю о простоте конечного прикладного кода, я говорю об архитектуре. Любое кастомное XML-RPC сложно в освоении и поддержке, как раз потому что оно кастомно. А интеграция разных RPC-сервисов друг с другом часто совсем невозможна из-за отсутствия адресуемости ресурсов, например.
Простота конечного кода обеспечивается библиотекой прикладного уровня, независимо от того, какие запросы она в провода генерит. Никто не спорит, что с ней было бы приятней. С чем я спорю — так это с тем, что XML-RPC интерфейс заменил бы собой написание такой библиотеки руками.
Кстати, от SOAP-интерфейс к поиску Google отказался (http://code.google.com/apis/soapsearch/). Просто потому что на практике он не «рулит» и не «бибикает».
Вообще, то, что вы просите — это не SOAP, а просто более высокоуровневая библиотека. Повторюсь, она скорее всего напишется под ваш любимый язык, если мы правильно будем продвигать дальше платформу.
Чтобы сделать универсальный блог клиент, нужен протокол application-уровня, который будет оперировать понятиями «пост», «автор», «фид», «категория» и т.д. И такой протокол есть — AtomPub (http://tools.ietf.org/html/rfc5023). И — сюрприз — именно он и используется у нас в части общения с блогом :-).
Также этот протокол используется в Blogger (http://code.google.com/apis/blogger/, Google Data — это расширенный AtomPub), WordPress (http://codex.wordpress.org/AtomPub). Кроме того, этот же протокол поддерживает такой известный блог-клиент, как Windows Live Writer: jcheng.wordpress.com/2007/10/15/how-wlw-speaks-atompub-introduction/. Я, правда, не видел глазами, насколько WLW будет работает с Я.ру через AtomPub, предполагаю, что не сразу (поскольку мы таки в бете ещё), но мы будем рады поработать над этим с серверной стороны, если кому интересно.
Другими словами, слова «с нуля» и «велосипед» применимы как раз к ad-hoc XML-RPC решениями, которые только с виду выглядят очень простыми.
Опять-таки, в зависимости от перспективы, он никогда и не начинал рулить :-). Чтобы не повторяться: softwaremaniacs.org/blog/2008/11/02/rest-vs-ws/
Использование WSDL сильно ограничило бы число клиентских платформ, поэтому это вообще не вариант. Что касается XML-RPC и REST, то поскольку они совершенно противоположны по идеологии, простота сильно зависит от того, откуда вы смотрите и какие у вас привычки. По мне, так совершенно идентичный подход REST к семантике редактирования и удаления, самоописывающиеся документы и прочие идеологические вкусности — это большой плюс.
> Ждем тогда официальную либу для этих сервисов для разных языков, как это делает гугль.
С либой всегда проще, да. Хотя я пока жду, что кто-нибудь напишет её быстрее нас :-).
+1. Еще плохо, что она с тех пор не развивается. А так как она все же много не умеет, я от нее в итоге отказался.
> и, поверьте, в консоли намного удобнее
Это примерно как объяснять пешеходу удобство АКПП. Или водителю — полезность зонта. В консоли удобнее, только если вы всю разработку делаете через нее, а если ее надо специально открывать и идти в нужную директорию только для того, чтобы сделать svn commit, то это дико неудобно.
> Семантика нужна для всего, в том числе для отображения любым
> образом, отличным от того, что вытекает из синтаксиса.
Это, в общем, верно, за вычетом того, что из синтаксиса (HTML'а) вообще никакого отображения не вытекает.
> Всё, что браузер может сделать таким образом, это положиться на
> семантику CSS, расчитанную как раз на отображение.
CSS семнатикой не нагружен. Просто по спецификации. Если вы вещаете на элемент <span> свойство display: block, он не становится блочным семантически. Например, запихивание в него <div> не станет вдруг легальным.
> специфические элементы гипертекста.
> не описать, как я понимаю.
CSS'у это не нужно описывать. Он предоставляет базовые возможности для оформления произвольных иерархических документов. А также определяет такое понятие, как "replaced element", про который говорится, что UA может рисовать его внутри, как считает нужным. Соответственно, UA, который знает о семантике HTML, знает, как внутри рисовать элементы форм, картинки и прочее.
(про остальное говорить не хочу, слишком обширная тема для короткого комментария)
Семантика не нужна для *отображения* XML'а. И браузеры прекрасно умеют отображать XML, применяя к нему CSS. Смысл (семантика) нужен для вещей, которые находятся сверх отображения чтобы элементы "работали правильно". Браузер делает из тега <a> кликабельную ссылку, потому что знает, что у тега <a> такая семантика. Любой другой элемент любого XML- или HTML-документа тоже можно стилизовать под ссылку. Выглядеть оно будет также, но "Открыть в новом окне" браузер для нее в меню не покажет.