Обсуждение вопросов разделения клиентской и серверной части, а так же расширения веб-ориентированного функционала

Предпосылка такова:

0) Нужна полная независимость от графики 
(разделение на сервер и клиент)
1) Нужна интеграция во всякие социальные 
сети и веб-сервисы
2) Для быстрой разработки веб дополнений 
предполагается использовать более
другой язык (питон)
3) Питоновский функционал предполагается 
быть или в виде плагинов, или в
виде полноценного фронтэнда (обсудить 
плюсы и минусы обоих подходов)
4) Обсудить разделение функционала на 
серверную и клиентскую части

Original issue reported on code.google.com by drmoriar...@gmail.com on 2 Sep 2009 at 1:33

Не понял насчёт интеграции во всякие 
веб-сервисы: что под этим понимается и 
зачем 
это надо?

Предполагается, что серверная часть 
куберока сможет крутиться на сервере 
вконтактика 
и вещать музыку одноклассникам? Или же речь 
идёт о встраивании звукового объекта в 
веб-страницу, наподобие видеообъекта на 
ютубе?

Original comment by nomen.in...@gmail.com on 2 Sep 2009 at 6:28

Раскрываю мысль полнее:
Есть всякие фичи, без которых не жить: 
скачивание обложек и текстов песен, 
скробблеры
всякие, интеграция с социальными сетями 
(последнее время пристально смотрел на
твиттер и на оpendesktop), прочие сервисы типа 
jamendo and ko, с поддержкой которых
можно начинать слушать музон на пустом 
компе...

И тут начинаются проблемы: то у lyricwiki 
протокол поменяется, то в libre.fm
функционала добавят, то опять же 
вконтактники... и в существующую монолитную 
базу
вносить изменения всё сложнее и сложнее, 
больше вероятность ошибок и конфликтов.
Кароче, назрела необходимость редизайна 
внутренней структуры.

В первую очередь предполагается сделать 
следующие вещи:

1) выделить сервер на подобие mpd. Он будет 
держать базу данных коллекции и
предоставлять собственно возможности 
проигрывания, как из коллекции, так и
локальные/удалённые источники. Надо решить 
с методом настройки параметров сервера, от
какого пользователя запускается сервер, и 
прочие низкоуровневые вопросы. Интерфейса 
к
серверу предполагается два (как минимум), 
первый (он же основной) через
qsharedmemory, с точки зрения 
мультиплатформенности самый 
безпроблемный вариант.
Второй интерфейс будет через d-bus (скорее 
всего), для прочих возможностей управления.

2) Клиентская часть будет рулить всеми 
сетевыми делами, картинки, лирика, 
скробблинг,
бесплатные и платные сервисы (в том числе 
вконтактники, может и на фейсбуке что-то
интересное есть...). Для маргиналов и меня 
будет консольный клиент с минимальной
функциональностью чиста для музона.
Для реализации клиента нужно выбрать один 
из двух подходов: плагинная система из
разнородных модулей (например минималка на 
с++ и куча загружаемых плагинов на
питоне), и однородная, возможно монолитная, 
система (например весь клиент на питоне
без плагинов, или то, что есть сейчас на с++)

Камрад a2k0001@gmail.com шарит в питоне и других 
умных вещах, его полностью питоновый
плеер светился на лоре недавно. Если он 
заинтересуется нашим предложением по
объединению усилий, то будет зер гут, ибо 
сам я в питонах и прочих высокоуроневых
языках не шарю.

Original comment by drmoriar...@gmail.com on 3 Sep 2009 at 5:34

Если честно, я никогда не разделял идею 
музыкального демона. Т.е, возможно это и 
удобно тем, что не надо постоянно держать 
запущенной интерфейсную часть, это не 
такой большой плюс, по-моему. В наличии 
серверной части лично меня утомляет то, что 
её нужно прописывать в скрипты или 
автозапуск. Это плохо, потому что мне не 
всегда 
нужно, чтобы оно запускалось само. Иногда 
хочется просто запустить пару треков, 
которые тебе прислали по почте. У mpd их 
вообще надо предварительно в коллекцию 
добавлять. Серверная часть лишает 
проигрывателя мобильности. Под 
мобильностью я 
лично подразумеваю именно быстрое 
использование, как описал выше, но и 
возможность 
запускать проигрыватель "с флэшки" тоже 
сюда входит. Клиент-сервер - это хана 
мобильности в большинстве реализаций.

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

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

Кроме того, лично я, опять же, всегда видел 
правильным решение в виде: основная 
программа делает только одно: позволяет 
плагинам общаться друг с другом через неё. 
На мой взгляд, любой функционал в 
программе, который может кого-то не 
устроить, 
должен иметь возможность быть заменённым 
более подходящей реализацией. Тут я в 
первую очередь намекаю на коллекцию - 
потому что я сейчас страдаю от отсутствия 
проигрывателей с подходящей для меня 
реализацией коллекции. И ещё я сейчас 
осознаю, 
что хочу иметь как минимум две отдельных 
коллекции музыки, да ещё и в разных 
форматах.

Как я понимаю, у Вас уже созрела мысль, что 
скробблинг на last.fm и libre.fm должны 
быть сделаны плагинами. Полагаю, что Вы уже 
задумываетесь о том, как сделать так, 
чтобы эти плагины работали в демоне, а 
настраивались в клиенте. Я не уверен, что 
это 
можно сделать изящно и красиво. Если Вы 
считаете, что скробблинг должен вертеться 
в 
клиенте, то, боюсь, это сведёт на нет все 
плюсы клиент-сервера, потому что клиент 
придётся держать постоянно запущенным.

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

Итак, какие я вижу проблемы в предложенной 
Вами организации:
1. Раздельный запуск клиента и демона. Это 
далеко не так удобно как кажется. 
Полагаю, однако, что решить этот вопрос 
всё-таки можно несколькими настройками, 
приводящими к поведению, похожему на 
поведение простого проигрывателя: при 
первом 
клиента (при незапущенном демоне) выясняем 
где бинарь демона, вписываем его в 
глобальный демонский конфиг, запускаем 
демона из клиента дочерним процессом 
(можно 
не сразу, а при нажатии кнопки play). 
Добавляем в настройки параметры, 
позволяющие 
при выходе из клиента останавливать так же 
и демона. В идеале - добавить вариант, 
кода демон работает не отдельным 
процессом, а всего лишь тредом в клиенте. 
При 
запуске второго клиента искать демона и не 
запускать его лишний раз.

2. некоторая часть плагинов будет работать 
в сервере, а настраиваться из клиента. 
Например, коллекции (предполагаю, что мы 
уже согласись их в плагины вынести) или 
скробблинг (полагаю, опять же, что мы 
приняли решение, что в клиенте он 
неэффективен). Кстати, необходимость 
коллекции в демоне, по-моему, несколько 
преувеличена. На мой взгляд, это несколько 
не вяжется с вконтактиками, которые в 
клиенте. ИМХО, непоследовательно. Полагаю, 
что основной программе могло бы быть 
вообще безразлично, откуда трек: из 
вконтактика или из библиотеки. Т.е. на мой 
взгляд, эти два плагина могут 
реализовывать один и тот же интерфейс.

3. предлагаемые системы плагинов: полагаю, 
идеальным вариантом будет середина: часть 
плагинов на c++, часть на пайтоне, в основной 
программе только каркас для плагинов. 
Как я понял из темы про VPlayer, камрад A2K не 
особо заинтересовался, поэтому лучше 
перестраховаться. Кстати, можно опять же, 
как в амароке - не только пайтон, там 
можно на чём угодно написать, хоть на BrainFuck.

В общем, я рад, что мы затеяли это 
обсуждение раньше, чем клиент-серверная 
система 
заработала.

Original comment by nomen.in...@gmail.com on 3 Sep 2009 at 7:01

В целом поддерживаю. Плагинистая коллекция 
рулит, скробблинг в сервере - может так и
надо. Дополняю следующими предложениями:

0) Общая клиент-серверная архитектура не 
помешает собирать специальный вариант 
блоба
- всё в одном (мне кажется, что для macosx так и 
придётся делать)

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

2) Да коллекция как плагин это сильно, 
поддерживаю.

3) Есть ли какая нибудь общая инфа по 
питоновому плагиностроению? Мну, к большому
сожалению, не в курсе :-(

Что касается камрада A2K, он вчерась по 
гтолку выяснял границы моей 
компетентности и
высказывал замечания по коду и реализации. 
Посмотрим будет ли процесс иметь 
продолжение.

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

Original comment by drmoriar...@gmail.com on 3 Sep 2009 at 7:19

> 3) Есть ли какая нибудь общая инфа по 
питоновому плагиностроению? Мну, к большому
сожалению, не в курсе :-(

Я нашёл такую интересную иллюстрацию "как 
это работает" в KDE. ИМХО - жесть:
http://mail.python.org/pipermail/python-list/2003-November/235174.html

========================
... [Python] Panel
applets need a .desktop file which specifies the .so lib to
load. The .so specified is symlinked to the proxy, so it's
filename is correct and unique, but still runs the proxy code.
(There's a fake .la file in this case too, since the loader
expects one)

The .so proxy starts another .so that wraps the Python
interpreter, and from the config file name that the plugin
loader passes in it computes the name of the .py file. The .py
file is loaded into the interpreter, and the Python factory
function is located and called. That constructs the actual
applet (from Python via PyKDE/PyQt). A PyObject is returned to
the proxy .so which uses sip/PyKDE to convert it to a C++
pointer to the required type which is passed back to the loading
app. ...
========================

можно взять за основу вариант как в amarok. Там 
всё проще, там скрипты, которые 
общаются с амароком через dcop/d-bus, 
практически, эти скрипты можно запускать 
из 
любой консоли.

Original comment by nomen.in...@gmail.com on 3 Sep 2009 at 7:56

Выношу на обсуждение модель новой 
структуры.

Пояснения к модулям:
d-bus: внешнее управление реализованное 
хоткеями или чем угодно
audio: собственно модуль вывода звука (то, что 
сейчас player_...)
scrobbler: любой модуль следящий за 
проигрыванием (скробблинг, твиттинг, что 
угодно)
source: графический модуль источника музыки 
(сейчас его роль выполняют коллекция,
библиотека, file browser и сервисы интернет)
playlist: собственно плейлист
infowidget: это инфа о песне, альбоме, 
исполнителе, обложка, текст песен (всё, что
можно показать в контексте проигрывания)
info obtainer: это добытчик информации для 
контекстного показа

Стрелками показаны потоки информации, 
сигналы. Кроме связи source->playlist, которая
происходит через drag-n-drop (что делает source 
необязательным компонентом, его может
заменить любой источник драг-н-дропа 
урлов). Все клиентские модули, кроме info
obtainer, имеют графическое представление (то 
есть свой QWidget), и встраиваются в
приложение, например каждый в свой QDockWidget.
Естественно модулей одного типа может быть 
любое количество. 

Мне не совсем ещё понятна связь infowidget->info 
obtainer. Если их делать
независимыми, то нужно унифицировать 
запросы на инфу или захардкодить возможные 
типы
информации, получаемой из инета. (может их 
действительно объединить?)

Ну и вообще коментарии :-) насколько данная 
структура позволит расти дальше.

Original comment by drmoriar...@gmail.com on 4 Sep 2009 at 5:35

Attachments:

modules.png

Это то, что нужно, во всяком случае, я тоже 
не представляют других вариантов. Только 
я бы на схеме ещё добавил связь source->infowidget 
(или source->info obtainer) 
потому что последний может брать инфу о 
размере, расположении и т.п. 
характеристиках 
файла от него.

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

"Ввод приоритетов" для info obtainer представляю 
себе так: "вы активировали плагин, 
который предоставляет информацию о треке: 
[текст песни, обложка], в то время, как у 
вас уже работает плагин, который берёт всю 
инфу из базы данных, там тоже есть [текст 
песни]. варианты: отключить плагин с базой 
полностью, брать [текст песни] от нового 
плагина, остальное - из базы, не включать 
новый плагин"

В то же время, теретически infowidget может быть 
(стандартный) в виде простого 
виджета, как в текущем варианте или 
(сторонний плагин) в виде неоновой вывески 
с 
обложкой в витрине и текстом в виде бегущей 
строки.

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 5:54

Хотя, я нашёл недочёт. У нас сервер получает 
теги от клиента. Если клиент не запущен 
- что за инфу сервер будет давать 
скробблеру?

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 5:57

Тогда считаем, что пусть так и будет.

Ещё хочу обратить внимание, что реализация 
супер-навороченной-коллекции-классики
потребует примерно следующих телодвижений:
1) собственно бд для хранения всех полей 
тегов (и виджет с функциями поиска/фильтра)
2) расширенный плейлист, который будет всё 
это буйство красок отображать
3) надо что-то решить с форматом 
передаваемых тегов, чтобы все остальные 
плагины
зависящие от tags могли работать по прежнему. 
(мы же ещё про tageditor забыли,
учитывая, что source не обязан предоставлять 
доступ на запись, tageditor'а надо
вызывать из playlist'а)

Про теги предлагаю захардкодить несколько 
уровней, каждый последующий обязан 
включать
в себя предыдущий.
tag 0: то, что считается тегами сейчас
tag 1: + то, что понадобится для 
супер-навороченной-коллекции-классики
tag 2: на будущее

Original comment by drmoriar...@gmail.com on 4 Sep 2009 at 6:23

ответ на коммент 8:

а на сервере и плейлиста нету, так что при 
упавшем/выключившемся клиенте, сервер
доигрывает текущую композицию и 
останавливается

Original comment by drmoriar...@gmail.com on 4 Sep 2009 at 6:24

Точно, нету... А зачем сервер отдельным 
процессом?

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 6:47

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

Но в настройках компиляции всё равно будет 
галочка "собирать монолит" :-)

Original comment by drmoriar...@gmail.com on 4 Sep 2009 at 7:12

> Но в настройках компиляции всё равно 
будет галочка "собирать монолит" :-)

Значит, я вообще напрасно беспокоился 
насчёт минусов клиент-сервера.
=============

Теперь про теги и мегаколлекцию.

Abstract:
Плейлисту отдают модель, в метаинформации 
которой можно сохранить что угодно, в том 
числе QVariant с хэшем - предлагаю там и 
сохранить хэш-словарь, сопоставляющий 
мнемоники полей с тегами в id3 и vorbiscomment и 
обратно, возможно, для каждой 
композиции отдельно. Я не знаю, как 
устроены ape-теги, про них промолчу, но, 
думаю, 
можно экстраполировать и на них. Это всё 
хорошо, действительно, пока речь не заходит 
про, например скробблинг.

BrainStorm:
1) Вариант с "захардкодить несколько 
уровней", хорош, только я предполагаю их 
"засофткодить", то есть обязать 
предоставлять информацию о треке в разных 
уровнях 
абстракции: либо старый дедовский либо 
новый современный, например, используя 
полиморфизм. Но вообще, этот метод кажется 
мне наименее оптимальным, так как он 
наименее настраиваемый. С другой стороны, 
под него всё равно подходит следующий 
вариант.

2) опять же, модель. Для отображения инфы в 
плейлисте у неё запрашивают данные по 
индексу, т.е. в этом случае всё буйство 
красок не требует дополнительной 
поддержки 
плейлистом. Для скробблинга можно 
непосредственно у модели запрашивать 
непосредственно же нужные данные, что-то 
вроде model->getArtist(); mode->getAlbum() 
и пусть само решает, что отдавать. Редактор 
тегов при этом всё-таки придётся 
переделывать под новый вариант коллекции.

3) Очередной вариант: как в предыдущем, но 
коллекция реализует свой редактор тегов. 
Т.е. для файлов не из коллекции - редактор в 
текущем виде. Для файлов из коллекции - 
редактор, поддерживающий все навророты 
коллекции.

может, ещё варианты придумаю

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 8:15

Кстати, я осознал в чем разница между 
"плейлист получает модель от коллекции" и 
"плейлист добавляет в эту модель трек не из 
коллекции". Думаю сильнее.

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 8:28

Вариант:

Можно придумать некий modelJoiner: модель от 
коллекции, модель от другой коллекции, 
модель от filebrowser, модель от drag'n'drop 
объединяются в одну модель.

Метаинформация "хэш-словарь, 
сопоставляющий мнемоники полей с тегами в 
id3 и 
vorbiscomment и обратно" хранится для каждого 
тега, либо хранится только информация об 
источнике трека и словарь запрашивается у 
источника при необходимости.

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

Плейлист в таком случае выглядит примерно 
как в амароке 2.0: в кратком состоянии 
отображается "название композиции"; тип 
альбома, дата концерта и что угодно ещё - 
при 
воспроизведении или по дополнительному 
запросу. Кстати, давно хочу предложить: для 
форматирования плейлиста можно встроить 
синтаксис, подобный tagz из foobar.

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 9:09

>Кстати, давно хочу предложить: для 
форматирования плейлиста можно встроить 
синтаксис, подобный tagz из foobar.

Поподробнее плиз, сабжем не пользуюсь

Original comment by drmoriar...@gmail.com on 4 Sep 2009 at 9:32

Я тоже в последнее время пользуюсь только 
mplayer, smplayer и cuberok. Однако про 
tagz ходит молва. Это что-то вроде краткого 
языка программирования, встроенного в сам 
проигрыватель. Он может условные операции 
($if(), []) математические операции ($add
(), $mul(), $div()), текстовые операции ($substr()), 
среди функций основные - 
$artist, $title, $year - метаинформация текущего 
трека (есть ещё $meta, которая 
получает значение тега по его названию), 
остальные вроде как для форматирования.

Этот язык используется для шаблонов 
заголовка окна, всплывашек, OSD и прочего, 
этим же 
языком описывается каждая строка 
плейлиста. Он там везде.

описание:
http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Reference
примеры:
http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Preferences:Album_List
http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Album_List

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 9:49

что касается языка, может хоть для этого 
подойдёт QtScript? Самому изобретать язык
(даже описательный) ой как неохота

Original comment by drmoriar...@gmail.com on 4 Sep 2009 at 10:16

> может хоть для этого подойдёт QtScript

язык есть - использовать его негде? )))
Надо посмотреть, это всегда можно оставить 
на потом.

Original comment by nomen.in...@gmail.com on 4 Sep 2009 at 10:32

Harinlen / cuberok

Обсуждение вопросов разделения клиентской и серверной части, а так же расширения веб-ориентированного функционала #66