это все для клиента на ведройд?

и будет на jsonrpc?

Вот давайте максимально полный апи, можно будет тогда упростить/улучшить лор-стат (http://lor-stat.com/)

Вот давайте максимально полный апи

Лучше бы конкретные предложения, что должно в этот максимальный api входить.

это все для клиента на ведройд?

Я бы и на десктоп себе клиент сделал.
Ну и для мобилок полезно будет.
От себя обещаю, что не менее чем за полгода сделаю клиент для MeeGo/Android/iOS с интерфесом на OpenGL.

и будет на jsonrpc?

Мне ближе xml over http.

Возможность постить через АПИ нужна, иначе ненужно.

Сразу скажу, что я в web-программировании понимаю еще меньше, чем в Java, так что очень уж твердыми какашками попрошу не кидаться.

а зачем топик создал?

В моем представлении, движок не придется переписывать совсем. Это одно из основных тербований к проекту. Необходимо добавить в движок несколько фич, которые не будут видны тем, кто ими не пользуется.

злобно хихикает

а зачем топик создал?

Так ведь я уже написал: «LOR-API сам не напишется». Вот и создал топик.

Получение текста уведомления по номеру.
Получение текста последнего уведомления.
Получение списка разделов.
Создание треда в указанном разделе.

sudo cast CYB3R, stevejobs, Slavaz, r_asian, Legioner, ls-h, kam

Я свои пожелания по этому поводу неоднократно высказывал, но если кратко: нужно прикрутить OAuth, информацию нужно отдавать в форматах JSON или XML на выбор.

Выскажу своё "веское" мнение.

НЕНУЖНО! Ну, мне по крайней мере.

А вот от почтового списка рассылки вместо RSS не отказался бы.

Имея API список рассылки пишется за один-два вечера.
Но я соглашусь, все же это несколько иная сущность.

А в интернете нет сервисов для отправления RSS на e-mail?

Лишние телодвижения, и сервисы. Да и на отдающей стороне можно запилить ряд доп. фич.

А давайте вместо страдания ерундой спонсировать важные свободные проекты? Например, тут кому-то сильно нужна поддержка последней IOS в онтопике, так давайте пилить libgpod.

важные свободные проекты

поддержка последней ненужно в ненужно, так давайте пилить ненужно.

кому-то сильно нужна

Пусть тот, кому нужна libgpod ее и пили.

важные свободные проекты

ЛОР - свободный проект. Он занимает в моей жизни намного больше места, чем libgpod (Если быть точным, то в бесконечно раз больше, т.к. libgpod в моей жизни места вообще не занимает)

спонсировать важные свободные проекты

Тогда предлагаю рассматривать действительно важные и еще раз пропиарю http://donate.libreoffice.org/

P.S. Пользователи продукции Apple должны страдать.

Ага, оказывается не только меня давно мучает этот вопрос. Если сделать не просто API, а еще и вот так, то у каждого будет свой удобный ЛОР, векторный и гипертекстовый.

libgpod первым пришел в голову, потому что о нем здесь часто кричат. «Ваш линукс говно, мой айпэд в нем не работает!!11» встречается нередко. Вот, действительно, libreoffice нуждается в помощи, в mcu8051ide нужно добавить поддержку большего кол-ва MCU и т.д. А вы тут на ЛОР деньги собираете.

А зачем вообще лезть в lor-source? Есть база - есть api. Для анализа и 100% попадания в требуемый функционал, достаточно посмотреть на те запросы, что уже реализованы и не надо никаких «необходимых, как кому-то кажется, функций». А про id сообщений - вообще доставило.

я, в общем-то, не против, а, скорее, за это

Запилить поддержку получения текущего опроса и голосования, правки сообщений и тем, заливки скриншотов в галерею, создания опросов.

Есть база - есть api

Вот к этой базе и пытаемся api придумать, она ведь наружу сейчас никак не торчит.

Каждый занимается тем, что ему интересно и важно.
Либре я денег скинул, теперь хочу лор осчастливить.
А mcu8051ide пусть пилят те, кто им пользуются.

до Spring Security стартовать бесполезно. Лучше помогите протестить и проревьювать SS, а LOR-API как-нибудь сам напишется...

Лучше помогите протестить и проревьювать SS

Мои познание в Java весьма скудны, так что вряд ли я тут хороший помошник.

Как я понял, SS будет использоватся на ЛОРе для аутентификации и до тех пор, пока он не появится, API можно не ждать?

Отличная идея, давно ждемс. Тогда можно будет и клиенты написать, чем я бы и занялся от нефиг делать.

Мне кажется, лучше было бы научиться «выуживать» свежие сообщения из читаемой темы и автоматом впихивать их на страничку.

В общем, я все еще движим идеей «бесконечной» темы с подгрузкой каждого сообщения в виде html в динамически добавляемый блок (div или iframe).

Это позволило бы не грузить целиком длиннючие темы, а просто переходить по нужным сообщениям. Кроме того, в этом случае можно было бы реализовать 100500 видовых представлений ЛОРа.

Lor-api как раз сам и напишется, решите сначала лучше более важные проблемы

Хочу видимые ответы как на 2ch.so

Для этого надо с нуля переписать движок ЛОРа. И явно не на Java…

Нет, не надо

тогда получится жирное и неповоротливое нечто

Раз уж будет всё с нуля, то:

• Получение UA автора/комментатора
• Получение списка игнорирующих пользователей

Получение UA автора/комментатора

Бессмысленно. Лучше уж — ковыряние в его куках и получение реального имени автора (по его аккаунтам во фконтактиге, ЖЖшке, мордокниге, гуглоплюсе, однокамерниках и т.п.)

Получение списка игнорирующих пользователей

А игнор вообще отменить надо.

Бессмысленно.

Совсем нет, можешь сразу определить, пишет человек причастный, или так, мимо проходил. Ничего больше.

Лучше уж — ковыряние в его куках и получение реального имени автора (по его аккаунтам во фконтактиге, ЖЖшке, мордокниге, гуглоплюсе, однокамерниках и т.п.)

Ковыряние в куках через JSON API? Ну-ну.

А игнор вообще отменить надо.

Это не баг, это фича.

Я в UA могу хоть «Супер-пупер браузер на супер-пупер операционке» написать. И что?

Ковыряние в куках через JSON API? Ну-ну.

API уже давным-давно есть (все эти «лайки»)

ИМХО, у Фейсбука API почти идеальный (https://graph.facebook.com). Я бы делал аналогичный ему. Т.е. если с авторизацией - то каждому выдаем access_token, если без нее - то ничего не выдаем.
Затем, юзеры просто делают GET-запросы к серверу (например, http(s)://linux.org.ru/api) и получают результат в json'е.

Пример:

GET 'https://linux.org.ru/api/feed?access_token=blablabla&fields=id,title,text,author_name,author_id,timestamp&count=2&order=desc'

{
   "status": 0,
   "feed": {
        {
            "id" : 12345,
            "title": "Был убит Леннарт Поттеринг",
            "text": "Вчера вечером....",
            "author_id": 1,
            "author_name":"maxcom",
            "timestamp":1349770247
        }, 
        {
            "id" : 12344,
            "title": "Леннарт Поттеринг предлагает замену libastral",
            "text": "...",
            "author_id": 1,
            "author_name":"maxcom",
            "timestamp":1349740247
        }
    }
}

Получение комментов - как-то так:

GET 'https://linux.org.ru/api/12345/comments/?access_token=blablabla&fields=id,title,text,author_name,author_id,timestamp&count=2&order=desc'

Я в UA могу хоть «Супер-пупер браузер на супер-пупер операционке» написать.

Это тоже показатель, если что.

«Был убит Леннарт Поттеринг»

Эх, было бы это правдой...

Только не надо GET, надо POST

Вот как раз лучше GET.
По работе приходится иметь дело с АПИ разных соц.сетей. И плюс ФБшного как раз в обычных GET-запросах. А, например, в одноклассниках, чтобы сделать простейший запрос к API надо (пишу по памяти, могут быть неточности):
1. Зарегиться в ОК
2. Зарегиться в их JIRA
3. Получить всякие ключи
4. Сформировать POST-запрос
5. Лексикографически пары ключ-значение параметров
6. Сделать URL-encoding
7. Добавить ключ
8. Взять от этого MD5 и добавить этот ключ к запросу
9. Сделать запрос.

А в ФБ:
1. Взять свой access_token (и то, не обязательно для многих запросов)
2. Сформировать запрос и добавить токен
3. Получить результат

А в ФБ

Ну вот, сделай s/GET/POST/, и совсем хорошо будет

Ну вот, сделай s/GET/POST/, и совсем хорошо будет

А чем GET не угодил?

Его можно просто в адресной строке браузера набрать

Да, и в браузере получить результат. И в чем проблема-то?

И чем это плохо?

Я понимаю, если бы для запроса нужно было бы передавать файл/xml/json/еще что-то подобное...Но ведь все нужное для запроса можно легко передать обычным GET'ом.

Результат:

Хорошо. Только надо еще id сообщения на которое ссылается сообщение, если это ответ. чтобы можно было дерево строить.

Хорошо. Только надо еще id сообщения на которое ссылается сообщение, если это ответ. чтобы можно было дерево строить.

Ну, я бы разделил Топик и Комментарии (как в ФБ - есть пост, а есть комменты к нему). Либо отдельным полем выводить тип сообщения - тема или коммент.

В ФБ посты и комменты разделены. Пост содержит массив comments, комменты получать нужно отдельным запросом, передавая id поста.

В Твиттере все твиты одинаковы, но есть поля in_reply_to_user_id и in_reply_to_status_id - там указываются id юзера и твита, ответом на который является данный твит.

В общем-то, оба подхода возможны.

второй вариант для ЛОРа ИМХО больше подходит. Пост без комментариев здесь традиционно «не нужен», а вот возможность строить иерархию комментариев многие оценят.

а вот возможность строить иерархию комментариев многие оценят.

Не просто оценят, а очень-очень обрадуются. Т.к. на 10 страничном треде узнать что ответили Васе Пупкину на комментарий на первой странице ой как сложно.