Нужна здоровая критика

На русском бы покритиковал, а так...

Хотя, вот в чем вопрос: в чем облачность аггрегатора?

Хотя, вот в чем вопрос: в чем облачность аггрегатора?

Имеется в виду, что он не сидит на твоём локальном компе. Он сидит где-то в сети, а ты ходишь на него откуда хочешь.

Насколько я могу судить, термин «облачный» последнее время означает только и исключительно это.

Написано вроде понятно. Адекватность самого протокола не оценю, предметная область мне незнакома.

Уже приятно, спасибо.

Написано тяжело. Например, нет нужды постоянно повторять " (REQUIRED) - this member MUST be a string, which uniquely identifies" несколько раз (см 1.6). Можно было бы попытаться описать куски протокола в виде формальной грамматики.

Непонятно с id. Кто его должен придумать и какие правила?

Конечно все выше ИМХО.

читается, действительно, тяжело. может быть, вместо:

«target» (REQUIRED) - this member MUST be a string
«params» (REQUIRED) - this member can be any valid JSON value.

писать как-то так:

required:
* target: string
* params: JSON. any valid JSON value

Вобще не хватает элементарного форматирования. Хотя бы как на http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html

Например, нет нужды постоянно повторять " (REQUIRED) - this member MUST be a string, which uniquely identifies" несколько раз (см 1.6)

Ну, я на RFC-шки смотрел в качестве примера.

Можно было бы попытаться описать куски протокола в виде формальной грамматики.

Можно попробовать. BNF в данном случае хреново подойдёт, ибо порядок полей в JSON-объектах традиционно не важен, и я не хочу что-то в этом менять.

Непонятно с id. Кто его должен придумать и какие правила?

Клиент придумывает свой, который пишет в командах add-source и add-stream. Сервер вправе отвергнуть его. Например, возможно, что пока клиент думал, другой клиент уже сделал стрим или соурс с тем же id. Или серверу просто что-то не понравилось. Тогда он придумывает свой. Но: в пределах одного запроса клиент вправе использовать свой собственный id, ибо тот, который придумал сервер, он ещё не знает.

Подумаю, как написать это более внятно.

писать как-то так:

Спасибо, подумаю над этим.

Хотя бы как на http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html

М-м-м... всё-таки хочется сохранить некий RFC-шный дух.

т.е. по вашему банально веб приложение == облачное?

Общие замечания:

Лично у меня возникло ощущение отсутствия какой-то целостности описания. Я бы делал так - каждый пункт второго уровня типа 1.3, 1.4 описал бы в общем виде, мол, состоит из того-то, того-то и того-то, рассказал бы как это всё между собой связано и взаимодействует, а потом бы уже подпунктами описывал. Сейчас я собираю общую картину из маленьких деталей - меня это угнетает. В идеале структура описания была бы такой:

• Определение ( что это такое? )
• Описание ( зачем это нужно ? )
• Интерфейсы ( с чем связано? )
• Логика ( как это работает? )
• Исключения ( как это не будет/не должно работать)

Коли это спецификация протокола, то стоит избегать неопределенных выражений (better, too quickly)

Почему только Atom? RSS 0.99/1.0/1.1/2.0 не?

Форматирование стоит улучшить как минимум добавлением маркированных списков в описании команд.

Не вижу логики в структуре спеки, я бы сделал так:

0. Preliminaries

1. General description

2. Scope of the protocol

3. Server side

3.1 Server components

3.2 Server configuration

4. Client side

4.1. Client components

4.2. Client configuration

4.3. Client operations

5. Operations

5.1. Getting the content

5.2. Modifying the configuration

6. Optional components

Есть ли какое-то разграничение доступа для команд модификации конфигурации сервера? Или сервер для каждого клиента хранит отдельную конфигурацию?

C id вообще всё как-то сомнительно. Представим такую ситуацию. Вы пришли к успеху и сервер PersonalFeed обслуживает 1 млн. клиентов. Допустим какой-то добрый человек сделал годную библиотеку для PersonalFeed, которой пользуется 90% клиентов. Эта библиотека использует какую-то определенную схему генерации id, например, req-%N%. А теперь представьте, сколько времени будут терять ваши клиенты на перегенерацию id, т.к. серверу будут приходить сотни тысяч одинаковых id и он их будет отвергать.1

По конкретным пунктам:

Abstract бы расписать побольше. Во-первых, что это вообще такое? Каковы предпосылки создания этого протокола? Какие задачи этот протокол решает? Какие задачи решают участники этого протокола? Какой профит от использования? Какие есть альтернативы?

Пункт 1.2. 2/3 написанного рассказывает о том, что он не делает, а о том, что он делает всего одно предложение. «PersonalFeed protocol allows users to adjust the lists of items they read to their liking.». И то очень скудно - непонятно о чём речь вообще.

Пункт 1.3.1 «This set is not supposed to be fixed; however, it's better if it doesn't change too quickly.» - вы пишите спецификацию, поэтому фразы «better if it doesn't change too quickly», как мне кажется, неуместны. Кто определяет какая частота too quickly, а какая нет? Раз в минуту - это too quickly или нет?

Пункт 1.4. О какой конфигурации идет речь? Аппаратной? Конфигурации ОС? Конфигурации сервера PersonalFeed? Если последнее, то «In case the change of configuration is inevitable (for example, in case of the server software upgrade), the server SHOULD preserve as much of the configuration unchanged as possible.» - я бы поставил MUST, а не SHOULD. Ну, потому что это очень странно, когда мы обновили убунту, а у нас список фидов или фильтры изменились.

Пункт 1.4.3. Зачем вообще нужен sources, если он хранит параметры о provider? Не проще ли сделать id и params как подобъект provider? Какой-то неуместный реляционный подход. «Elements of the „sources“ array are called „sources“ in this document.» Ну зашибись! И как мне теперь отличать родительский объект от дочерних?

Пункт 1.4.4. Я не понял, что это вообще такое и нахрена это нужно. [Stream] URI MAY be relative, in which case it is considered to be relative to the entry point. А откуда я беру entry point? «Elements of the „streams“ array are called „streams“ in this document.» - опять же как отличать родительский от дочерних?

Пункт 1.4.5. Тоже не понял, что это.

Пункт 1.6.1. Зачем делать другой JSON, если случилась ошибка? Будьте проще - сделайте один формат, в котором будет поле статус = (Success|Error) и поле Response с массивом ответов (для error будет массив из одного элемента со строкой описания ошибки).

Пункты 1.6.3 - 1.6.9. Плохо, что у каждой команды свой формат ответа на успех и провал команды. Имплементить обработку такой каши будет сложно. Лучше сделать один универсальный формат - так тупо парсить ответы проще.

Пункт 1.6.11. «The server MUST execute the commands in order.» - in order of what? Немного неграмотное с точки зрения английского предложение. Если я правильно понимаю, то надо «The server MUST execute the commands in order of arrival (receipt)»

Ух ты, сколько. Спасибо.

В идеале структура описания была бы такой

Стилистику обдумываю. В принципе, тут уже много замечаний на эту тему.

Почему только Atom? RSS 0.99/1.0/1.1/2.0 не?

На вход - RSS2 поддерживается. Предыдущие версии - м-м-м... не очевидно, надо ли. Если очень надо, можно сделать отдельного провайдера, и отдавай что угодно.

На выходе - да, только атом. А зачем дублировать в RSS?

Или сервер для каждого клиента хранит отдельную конфигурацию?

С точки зрения протокола никаких «отдельных конфигураций» нет, один сервер - один юзер (но, возможно, не один клиент). Естественно, ничто не препятствует серверу давать разным юзерам разные точки входа, или определять клиента по тому, как он авторизуется, и, соответственно, выдавать разные конфиги. Но этим пусть занимается HTTP(S).

А теперь представьте, сколько времени будут терять ваши клиенты на перегенерацию id, т.к. серверу будут приходить сотни тысяч одинаковых id и он их будет отвергать.

Может не отвергать, пожалуйста. Может выдавать те же самые обратно.

Основная заморочка вот какая: конфиг, который знает клиент, в принципе не может быть точно тем же, который знает сервер. Возможно, другой клиент добавил новый соурс или стрим, а мы пока об этом не знаем. Что должен делать сервер, если id пересекуться?

Во-первых, что это вообще такое? Каковы предпосылки создания этого протокола? Какие задачи этот протокол решает? Какие задачи решают участники этого протокола? Какой профит от использования? Какие есть альтернативы?

На последний вопрос ответить просто - никаких. По крайней мере, я не нашёл. Если бы нашёл, то воспользовался бы ею.

Остальное - да, согласен, нужно написать rationale. И заменить им пункт 1.2.

поэтому фразы «better if it doesn't change too quickly», как мне кажется, неуместны

Согласен. Это тоже надо куда-то в общее описание выносить.

Если последнее, то «In case the change of configuration is inevitable (for example, in case of the server software upgrade), the server SHOULD preserve as much of the configuration unchanged as possible.» - я бы поставил MUST, а не SHOULD. Ну, потому что это очень странно, когда мы обновили убунту, а у нас список фидов или фильтры изменились.

Увы, точно определить, сколько possible to preserve, ИМХО, невозможно. Тут приходится надеяться на здравый смысл программиста. Поэтому SHOULD.

И как мне теперь отличать родительский объект от дочерних?

Не очень понял. Как отличить список соурсов от одного соурса?

А откуда я беру entry point?

Если ты не знаешь entry point - то куда ты команды будешь посылать?

Будьте проще - сделайте один формат, в котором будет поле статус = (Success|Error) и поле Response с массивом ответов.

Если возникает ошибка с отдельными командами, то да - возвращаются отдельные ошибки в массиве. Ситуация, когда нам прислали вместо списка команд своп от винды - настолько исключительная, что, ИМХО, не надо смешивать его с более-менее нормальным выполнением.

Плохо, что у каждой команды свой формат ответа на успех и провал команды. Имплементить обработку такой каши будет сложно. Лучше сделать один универсальный формат - так тупо парсить ответы проще.

На провал у всех ответ одинаковый (ну, естественно, конкретные error messages могут отличаться). А на успех только две команды вообще какой-то ответ выдают, и эти ответы очень похожи.

«The server MUST execute the commands in order.» - in order of what? Немного неграмотное с точки зрения английского предложение.

Ну, выражение «in order» в значении «по порядку» вполне имеет место быть. Но да, надо бы сказать, что «в том порядке, в котором они приведены в запросе».

Ух ты, сколько. Спасибо.

На здоровье. Просто сам уже давно обмысливаю над гуглоридер заменителем и все эти темы с подписками мне весьма импонируют.

В общем, буду следить за вашими успехами. Готов на новые версии спеки покомментить.

Кто автор этого протокола и текста?

Второй вопрос: простым языком, что это за протокол и зачем он? Это точно не бесполезная трата времени?

Кто автор этого протокола и текста?

Я, само собой.

Второй вопрос: простым языком, что это за протокол и зачем он?

Сервер агрегирует новости, выдаёт их тебе как ты захочешь. При этом, если у тебя несколько девайсов, то любые изменения, которые ты вносишь на одном, видят и другие. Кроме того, можно настроить сервер так, чтобы пост, прочтённый (именно прочтённый) на одном девайсе, другие вообще не видели.

Это точно не бесполезная трата времени?

define бесполезная.

Если еще актуально, хороший пример:

https://dev.twitter.com/docs/api/1.1