Вышел менеджер закачек Steadyflow 0.1

Очень важно для программы, которая что-то качает иметь режим работы в виде демона. Умеет?

Не совсем понятно, почему это так _очень_ важно. На роутер ставить, что ли? Судя по dbus - нет. Тогда зачем?

Deluge/deluged знаете? Так у нас есть сервер качальщик/раздавальщик. Для большого числа людей.

Это правильная архитектура unix-way. Можно поставить на закачку и вылогиниться из ssh.

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

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

Да влом мне смотреть делюг (трансмиссия у меня, и вообще я редко торренты качаю), я не понимаю, какие выгоды это дает на десктопе. Да, можно сделать одновременный запуск, но зачем это делать, в чем тайный смысл? Чтоб при падении клиента сервер на упал? Ну так надо писать клиента, который не падает, его в любом случае надо такой писать.

ОМГ, долго тебе обьяснять.

1. Качает демон. Он надежный и автономный. Может работать на сервере без иксов, разработчики не морочат голову HIGом, а просто пишут качественную серверную программу. Все задача решена, качалка есть. Точка.

2. Для серверов делается webui и консольный клиент. Админы и гики довольны

3. Для десктопов делается гуйный клиент, который делают опытные гуеклепатели и не морочат голову себе разной серверной ерундой. Один гуй можно сделать на Gtk+, на Qt4. ВСЕ счастливы на десктопе. Домохозяйки счастливы, так как гуй при отсутствии демона в системе делает fork/exec и вообще никогда не говорит пользователю о существовании какого-то демона.

В итоге счастливы: админы, гики, домохозяйки, гномеры и кдешники = ВСЕ. Прекрасная модульность, гибкость и широта целевой аудитории

ОМГ, долго тебе обьяснять.

4. Это все есть в трансмиссии (ну может qt-шной морды нет, тулкитофобов мне не жалко), но тем не менее, когда я ее запускаю на десктопе - у меня один процесс.

5. Зато у нее нет какой-то кучи процессов с каким-то мутным RPC и прочим геморроем.

Нафиг ненужное месиво. Под каким пользователем будет работать демон? И как он раскидывает файлы в пользовательские директории (вопросы риторические). Такое деление имеет смысл делать только для раздачи торентов и т.п.

На самом деле код Steadyflow достаточно хорошо приспособлен для выделения качальщика в отдельный процесс. Базовые абстракции - это IDownloadService и IDownloadFile, которые общаются с гуём исключительно через сигналы. А уж сделать прокси-классы, общающиеся с настоящими через D-Bus - дело техники.

Другой вопрос, что поллить процесс через D-Bus каждые 200 мс (интервал обновления гуя сейчас) для вообще всех!!! файлов в списке - это всё-таки чересчур. Скачанные-то файлы будут скапливаться в списке, если их вручную не удалять.

Можно сделать как с Quassel. Там есть отдельный бинарник для кутешного клиента, отдельный для демона (к которому можно и по сети подключаться), и отдельный, в котором всё находится в одном процессе. Правда, для IRC для этого есть отдельная мотивация: можно запускать демон на удалённом сервере. А для качалки оба процесса всё равно должны располагаться локально, иначе в чём тогда смысл?

Один процесс - это как раз месиво. А относительно настроек, то это как сконфигурирует юзер, или по невозможности - мейнтейнер пакета. Для сервера, там админ разберется. А для десктопа, то пусть под юзером работает в режиме fork/exec. Главное что это будет одно и то же приложение для сервера и десктопа

Я вообще против того, чтобы гуй программы что-то делали. Только как фронтенды. Конечно имеются ввиду сетевые приложения. Кстати, фронтенд может быть не демону, а к библиотеке. А в программе только гуй, который использует либу. В консольной версии тоже, только обработка ключей командной строки, которые дергают ту же либу.

Но в данном случае лучше демон.

Ну это можно через любой IPC. Благо быстрых много. Можно прибегнуть в труъ-проверенных: FIFO, shared memory. Для fork/exec вообще pipes прямо напрашиваются

И конечно, sockets же

5. Зато у нее нет какой-то кучи процессов с каким-то мутным RPC и прочим геморроем.

То есть ты сначала выступаешь с позиции домохозяек, а потом для оправдания этой позиции приводишь технический аргумент. Красота :)

и отдельный, в котором всё находится в одном процессе

Но в этом нет потребности. Совсем нет, два процесса буду работать на ура

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

Куча - это один или два?

два и больше

Ты ж программист, должен знать, что есть только 3 числа - 0, 1 и куча.

Ааа... Ты еще curl посчитал. Ну есть ведь libcurl. Не проблема. Главное наявность безиксовой качалки и чтобы ее не пришлось заново писать. Для упоротых как ты я предложил использовать почти весь код в библиотеке. А к ней написать 3 программы: gui, webui, cli

Главное что это будет одно и то же приложение для сервера и десктопа

Всё ещё не понимаешь, что для HTTP... и прочих качалок серверное приложение не нужно. Городишь месиво технологий (в первую очередь) там, где они не нужны.

И просил привести фичи, нужные домохозяйке, которые невозможно сделать в одном процессе

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

Всё ещё не понимаешь, что для HTTP... и прочих качалок серверное приложение не нужно.

Yeah, right )))

О, уже лучше. Вот это я и подразумевал с самого начала, когда спрашивал, зачем демон. Я думал, что ты сразу скажешь о разных фронтендах к библиотеке. Но ты начал приводить в пример клиент-серверный делюг. А оказывается, что отдельный демон не сильно важен, важна модульность, а гики себе демона сами могут дописать, домохозяйком он все-таки не сильно нужен.

P.S. Только обзываться не надо, ок, тебе кдешников мало, что ты уже на своих кидаешься? ;-)

> Я вообще против того, чтобы гуй программы что-то делали. Только как фронтенды. Конечно имеются ввиду сетевые приложения. Кстати, фронтенд может быть не демону, а к библиотеке. А в программе только гуй, который использует либу.

Считайте, что сабж — гуй к GIO. Полегчало?

Демон может сильно ассоциироваться с init.d. Но я имел ввиду программу, которую можно запустить в screen и передать ей список файлов в файле, как wget -i. Только в отличии от него поддерживать большой набор протоколов. Потом можно будет к нему добавлять закачки, в том числе и через dbus, можно настроить в виде демона, без иксов все это. Так же можно управлять с гуя. Все довольны, проблем нет.

Дайте помечтать.

Не буду больше. Да и кдешников надо беречь. Ведь доставляющих еденицы, они всегда будут востребованы

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

>Не совсем понятно, почему это так _очень_ важно.

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