Замечание по ведению журнала

[vitus_wagner]

Если еще кто-то когда-то в моем журнале будет упоминать в положительном контексте что-либо, сделанное в рамках GNOME и KDE, буду банить как за мат.

Comments

[lxj.endofinternet.net (from livejournal.com)]

Что значит десктопное решение? При правильной сборке наверняка ничего GUI-шного он тянуть не должен.

Akonadi для того и пишется, чтобы почтовые клиенты не лезли в хранилище почты, адресные книги и прочее — а чтобы лезли в Akonadi, а тот уже в свою очередь разруливал проблемы синхронизации

[vitus_wagner]

Десктопное - в данном случае значит не сетевое. Сетевое решение - это на мой взгляд, такое, которое одинаково и прозрачно для пользователя работает и на локальной машине (причем без tcp и даже unix-domain сокетов), и по trusted локальной сети, и через аккуратно проколотую дырочку в файрволле, пропускающую только какой-нибудь один протокол удаленного выполнения команд (например ssh).

[lxj.endofinternet.net (from livejournal.com)]

Взаимодействие клиента и Akonadi происходит то ли через D-Bus, то ли через протокол, основанный на IMAP (всех деталей не знаю, ибо не разработчик). И то, и другое -- вполне прозрачны для сети (правда, скорее всего таки tcp. Но добавить возможность всего этого работать поверх ssh -- вряд ли непосильная задача)

[vitus_wagner]

Существенно то, что на поверхность вылезает API, а не протокол взаимодействия. На мой взгляд, это в корне неверная архитектура.

Если у нас есть текстовый протокол вроде imap, то писать клиенты для него можно на любом инструментарии который умеет читать/писать сокеты и пайпы.

Про API в описании можно и не упоминать. Да, можно при этом в дистрибутив положить какую-нибудь хелпер-библиотеку для работы с этим протоколом из C и C++ (потому что на этих языках простые вещи делаются сложно). Но именно как опциональную прибамбасину для любителей писать на низком уровне.

Задача написания клиента для текстового протокола (даже такого развесистого как IMAP с расширениями) на любом языке высокого уровня - куда проще, чем задача прикручивания к этому языку сторонней C-шной библиотеки. Особенно если ставить эту задачу как следует - с интеграцией в родной (или заранее выбранный) цикл обработки событий, в систему управления памятью (чтобы garbage collector ссылки на хэндлы объектов библиотеки правильно собирал при выходе out of scope. В GIMP вон с этим не справились).

[lxj.endofinternet.net (from livejournal.com)]

Вы принципиально не читали мой ответ? Ещё раз, для взаимодействия в Akonadi используется модифицированный IMAP (почему модифицированный тоже надо объяснять?). Ну, если мой соавтор не наврал в статье на KNotes, конечно :)

Кроме того, Akonadi поддерживает D-Bus -- открытый протокол, прекрасно работающий через сеть. Реализаций D-Bus для каких угодно языков -- вагон и маленькая тележка.

Я уж не говорю про pykde, ага

[dumendil.livejournal.com]

вспоминается такая замечательная старая машинка Amiga и её AmigaOS 8x-9x годов издания. там собственно интерфейс к ядру и основным системным библиотекам был через сообщения, асинхронный. ну и обычных врапперов для библиотек было достаточно, для традиционных программеров. но не в этом суть.

а суть в том, что был там встроенный скриптовый язык ARexx. а в его API/messages был такой вызов Declare (все имена и детали по памяти :) лет много прошло). Declare получал на вход указатель на стандартную процедуру и текстовую строку с объявлением рексовой фукнкции для этой процедуры, с типами параметров, их именами и прочим. и всё. теперь эту функцию этого приложения можно было вызывать из скриптов или из других програм через eval или из CLI сразу, как угодно.

в результате 90% софта под AOS, особенно гуёвого софта, декларировали свои основные процедуры. текстовый редактор, например декларировал всё, что может делать пользователь и немного сверх того.

что получалось в результате. любую гуёвую программу можно было вызвать из скрипта (кажеться даже не показывая интерфейса) и рулить ей оттуда же как угодно. а программы со своей стороны имели единый интерфейс для создания мощных макросов (как впоследствии VisualBasic попытались сделать)

я собственно это к чему. может это не идеальный с точки зрения архитектуры интерфейс, но он был а) простой, б) единый. а сейчас я подобных простых и одновременно мощных решений не вижу нигде. хотя я конечно сейчас не разработчик уже, может что-то и есть.

[taris_marh.livejournal.com]

Однако, тянет. По крайней мере в сборке для SUSE. Не будете же Вы собирать для своего супер-пупер приложения отдельную сборку. И как эта библиотека будет бодаться со своей GUI'шной версией за права доступа к файлам? И где тогда экономия?

Список requiremets можно посмотреть тут: http://rpmfind.net//linux/RPM/opensuse/10.3/i586/akonadi-3.93.0.svn712059-12.i586.html

Меня впечатлил.

Тоже вот мечтаю перегнать всю почту из мозилки в локальный IMAP, но вот несетевое решение, да ещё на Qt - спасибо, не надо. Skype, зараза, и так систему грузит этой Qt. Всё остальное-то на GTK. Не утверждаю, что GTK - гениальная штука, но мне он симпатичнее, да и все тспользуемые программы на нём.

[lxj.endofinternet.net (from livejournal.com)]

Ну, вы ведь понимаете, что это уже проблема сборки конкрентного дистрибутива?

app-office/akonadi-server/akonadi-server-1.1.2.ebuild:

RDEPEND="x11-libs/qt-core:4
x11-libs/qt-dbus:4
x11-libs/qt-sql:4[mysql?]
x11-libs/qt-test:4
x11-misc/shared-mime-info"
DEPEND="${RDEPEND}
>=dev-util/cmake-2.6.0
dev-libs/boost
dev-libs/libxslt
>=kde-base/automoc-0.9.88"

qt-core, qt-dbus, qt-sql и qt-test, понятное дело, даже от X не зависят (надеюсь, хотя бы qt-gui от всего прочего Qt в SUSE отделено?)

[taris_marh.livejournal.com]

Я Qt в принципе не люблю - писал под него, хватило. А в памяти оно висеть будет. Если бы не Skype (по работе нужен), вообще снёс бы.

Про SuSe не знаю, я Федорой пользуюсь.

[lxj.endofinternet.net (from livejournal.com)]

Я вот Gtk в принципе не люблю, например. Но если есть какой-то удобный инструмент, написанный с использованием gtk -- то использую его, а не кривлюсь на его страшненький вид в KDE4 (чем, кстати, Qt4-приложения в Гноме больше страдать не будут, начиная с Qt 4.5)