По поводу gmpc

Да, конечно, десктопные базы данных не должны использоваться на десктопах для хранения данных.

Фанатики..

Ужос в том, что gmpc - фронтенд к mpd, который УЖЕ с базой.

Мне тоже было бы куда приятней, если бы метаданные (каверы, тексты) mpd добывал и хранил сам в том же скулайте и их можно было бы забрать любым клментом. Это правильно, но сделать так правильно у меня скилов в Ц нехватает.

А мой любимый gmpc из клиента превращается в чудо-комбайн, использующий mpd лишь как бэкенд для проигрывания музыки. Qball'а понесло, печально это.

MPD все менее актуален на современном десктопе. Древний протокол с дерганием сервера за уши, когда D-BUS стала стандартом, невозможность проигрывания произвольных файлов, постоянно ломающийся ALSA-выход, отсутствие поддержки альбомов с разными исполнителями, ограниченный поиск, возможности, которые приходится реализовывать самим клиентам: last.fm, обложки, тексты, отсутсвие таки полноценных клиентов (только gmpc, да и в том поиск почти не реализован) -- это только часть. И вообще мне преимущества клиент-серверной архитектуры для десктопного проигрывателя непонятны. Зато явные недостатки есть -- быстрый as-you-type поиск, например. Вот и будет каждый клиент пытаться реализовать сотую часть Amarok'а со своим хранилищем данных и прочим пока MPD лежит в коме.

> И вообще мне преимущества клиент-серверной архитектуры для десктопного проигрывателя непонятны.

Разделение мух и котлет, aka UNIX-way. Плеер отдельно, гуй отдельно, а не windows-way/KDE-way с комбайнами «все в одном». Для пользователя толка, обычно (есть случаи когда есть, но это редкость) никакого, но так более грамотно. Гуй плеера нужен считанные проценты от времени использования плеера.

Не бывает, что просто так более грамотно. Не бывает просто метафизический unixway. Бывает, что есть архитектурный вопрос и варианты решений со своими за и против. Я один серьезный "против" назвал. Мне интересно, есть ли "за". GUI плеера прячется в трее или (как у меня) на своем workspace. Учитывая требования к современным плеерам, GUI все равно будет относительно тяжелым, и если он -- отдельный процесс, его никто закрывать/запускать когда хочется добавить композицию не будет.

> Мне интересно, есть ли "за"

Ну, например, музыку играет домашний сервер (подключенный к хорошей аудиосистеме), на котором вообще нет иксов. А управляешь ты им с рабочего компа/ноута/КПК (сидя где-нибудь в сортире по wifi:)) и т. д.

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

> Мне тоже было бы куда приятней, если бы метаданные (каверы, тексты) mpd добывал и хранил сам в том же скулайте и их можно было бы забрать любым клментом. Это правильно, но сделать так правильно у меня скилов в Ц нехватает.

В скулайте метаданные держит xmms2. Только он ещё довольно сыр для практического применения (музыку, конечно, играет, но нормальных клиентов для него я пока не нашёл, да и процессор грузит в разы сильнее чем mpd).

> Ну, например, музыку играет домашний сервер

ОК, принято. Хотя я говорю об адекватности на десктопе, тут немного другое.

> Также, клиент-серверная архитектура позволяет делать различные небольшие "примочки" (типа того же lastfm, иконки в трее и т. д.) в виде отдельных маленьких программ-клиентов (а не плагинов к одному "монстру")

Хорошо. Есть клиент T, который сидит в трее, L, который взаимодействует с last.fm, есть G - основной GUI. Что может делать L? Только посылать статистику на last.fm. Может он хотя бы сказать G, что track submitted? Нет. Может он показать рекомендации опять же в G, чтобы можно сразу было послушать? Нет. А клиент T так вообще максимум что может - картинку показать, да в менюшке play/stop/pause нарисовать. Если на него кликнуть, G спрячется/вылезет? Нет. В итоге для комфортного использования нужно всю функциональность L и T засунуть в G. При этом G не станет монстром, потому что это все базовая функциональность, ожидаемая от любого современного плеера. Либо вся функциональность G должна быть доступна остальным клиентам. Тогда почему G и сервер не объединить?