Hi Roman Odaisky
x64>>Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
RO>Портируй лучше APT. Все будут рады (кроме Шеридана).
Согласен. Правда гложут большие сомнения. Но еще лучшим дополнением к этому было бы изменить подход к пакетированию приложений. Тогда выигрыш от портирования APT был бы максимальный. Но вот на это рассчитывать не приходится.
Здравствуйте, Аноним, Вы писали:
x64>>Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
А>Может конечно для каких-то определенных классов приложений это и необходимо. Только обычной шароваре, не антивирусу/файрволу/еще какой критичной штуке, на мой взгляд автообновляться скорее вредно чем полезно. С точки зрения безопасности например отстойно, и я как пользователь 100% отключу такую функцию для приложений всех малоизвестных производителей. Мало ли чего им там в голову взбредет автообновить. Если софтина к интернету не имеет отношения, то тем более нечего ей туда лазить, да еще чего-то менять в системе в автоматическом режиме. Одно дело когда просто выводится диалог что типа — а вот новая версия кстати появилась, поди скачай если время есть. И совсем другое если оно само начнет жить своей жизнью, на фиг надо.
Как вариант можно сделать пункт меню "Check for updates", при нажатии на который будет открываться ссылка в браузере с номером версии (вида: http://www.example.com/MyCoolApp_check_for_updates.php?InstalledVersion=1.2.3.4). А сам скрипт на сервере будет сравнивать номер переданной версии и номер актуальной версии... и если нужно обновление — выдаст сообщение и ссылку на скачивание новой версии...
Это, больше подходит для маленьких приложений, у которых всего несколько файлов и каждое обновление меняет все файлы... Для громоздких же приложений, у которых куча файлов и в новой версии изменен только 1-2 — это не очень подходит... Хотя можно предусмотреть в серверном скрипте, чтобы для обновления выдавались только нужные файлы...
Кстати, к этому варианту можно прикрутить и другие фишки: например, на странице с обновление одной программы давать ссылки на новые версии других программ. Или сообщать какие-нибудь другие новости...
Здравствуйте, Carc, Вы писали:
>> Да не нужна библиотечка! Это уже вчерашний день. Нужно иметь системный сервис, в котором я могу зарегистрировать свое приложение и забыть об апдэйтах навсегда. C>А почему нельзя иметь 2 имплементации: как DLL, и как COM? Причем COM-объект вполне может использовать ту же DLL!?! Есть у меня одна софтина, причем мелкая и обновляться может достаточно часто. Весит все вместе!!! (включая ридми и прочий сопутствующий хлам) — 60 кило... Я что буду туда еще COM какой-то прикручать только из апдейта? Дык вряд ли... C>Имхо, а подход COM+DLL вполне: и волки сыты, и овцы целы?
Идея совершенно не в том чтобы тащить что-то со своим приложением, идея как раз в том, чтобы вобще ничего не тащить. Идеальным вариантом был бы системный сервис поставляемый компанией Майкрософт и встроенный в ОС. Я очень рад, что такое есть в Windows Vista (если верить посту выше). Уверен что и в следующих ОС это уже будет как правило, дабы избавить разработчика от ненужно гемора, а пользователя от различных вариантов апдэйтов различных приложений (у некоторых они на столько непродуманны, что необходимость в универсальном способе просто становится очевидной). Если у кого-то остался вопрос "Зачем нужна универсальная система?", отвечаю "Затем чтобы больше никогда не возникало желания изобретать очередной бесполезный велосипед и тратить своё время".
Здравствуйте, x64, Вы писали:
X>>Возможно я описал как-то сыровато, но идея примерно такая.
x64>Да уж, кривее некуда, хотя суть понятна.
Хорошо, что понятна.
x64> Только ты уже не первый, вон RO тоже пытается мне сказать, что выделенная для обновления служба лучше DLL, загружаемой в каждое приложение. Внимание, вопрос — а чем лучше-то?
У меня , например, нет желания да и времени ковыряться в интернете и искать библиотечки для авто-обновлений, сравнивать их, разбираться в API, встраивать их в приложение, писать отдельную логику для показа нужных окон в нужное время (а ведь это тоже часть системы авто-обновлений). Да и как показывает мой опыт, чем меньше с собой тащишь маленьких сторонних DLL тем легче потом будет жить. Для меня лучше чтобы в ОС был один универсальный системный сервис, у которого я могу дернуть один метод один раз и забыть. Разница в количестве проделываемой работы ИМХО на лицо. Видимо Майкрософт уже решили эту проблему начиная с Windows Vista. Это радует.
Кстати прошу заметить, в предложенном мной механизме контроль над обновлениями переходит на сторону сервера (разработчика) а не клиентской программы. И ИМХО это логично и так должно быть. А пользователь всегда имеет возможность отключить обновление приложения в независимости от того есть в настройках последнего такая галочка или нет.
X>>P.S. И конечно же этот сервис должен быть бесплатным, а уж как на нем заработать думайте сами
x64>Вот знаешь, поток сознания мне твой понятен, но вот эта фраза отбивает весь энтузиазм.
Энтузиазм в чем?
x64>Тебе оно надо?
Что оно?
Если у кого-то остался вопрос "Зачем нужна универсальная система?", отвечаю "Затем чтобы больше никогда не возникало желания изобретать очередной бесполезный велосипед и тратить своё время".
Только сомнительно что Microsoft сделает "универсальную машину", разве что "универсальную" только для нужд Microsoft, но только не для сторонних разработчиков...
Здравствуйте, x64, Вы писали:
А>>из фич которых я хотел бы видеть в updater А>>возможность оновлять запущенное приложение (хотя бы при следующем рестарте win) А>>возможность простого обновления нескольких файлов (на сервере файл со списком файлов которые надо обновить) А>>обязательно поддержка proxy А>>задание время и дату когда проверять обновления (или при каждом старте программы)
x64>Ну да, это самое основное и это я реализую в первую очередь.
Я реализовал автообновления для проекта Ammyy, могу поделиться мыслями и немного исходниками по этому поводу.
Пишите в личку.
Кстати, многие тут не поняли меня и решили, что я собираюсь реализовать целую систему автообновления. Ну вы, ребят, извините, но на мне и без того до хрена проектов висит, а вы хотите нахаляву сразу целую систему. Нет, для начала это будет простенькая более чем скромная .DLL (а может быть даже и .LIB сделаю), позволяющая что-то вроде этого
. Т.е. грубо говоря, это будет просто большой кусок кода, который я напишу вместо вас.
Термин "система автообновления" здесь не очень уместен, ибо подразумевает нечто масштабное. В будущем — да, но пока планирую только — логика checker'а, downloader'а, replacer'а и rebooter'а. Для многих, думаю, этого хватит за глаза.
ветке можешь отписаться.
M>...и немного исходниками по этому поводу.
Да нет, спасибо конечно, но они мне ни к чему, знаний особых каких-то или идей я вряд ли из них почерпну, — я, в принципе, и так "в теме". Но спасибо за предложение.
Здравствуйте, Carc, Вы писали:
C>Только сомнительно что Microsoft сделает "универсальную машину", разве что "универсальную" только для нужд Microsoft, но только не для сторонних разработчиков...
Возможно и так. Но это не означает того, что для обновления приложений не может и не должно быть универсального механизма.
Re[2]: Востребованность автообновления
От:
Аноним
Дата:
29.09.08 08:51
Оценка:
Здравствуйте, x64, Вы писали:
x64>Хм, смотрю я и думаю... а спрос-то есть!
Да вобщем-то и реализации есть. Для начала поищи по форуму, неоднократно обсуждали.
x64>Ну дык расскажи, какой функционал тебе нужен был? Мне, сам понимаешь, как автору_будущего_автоапдейтера_которым_будут_пользоваться_все_шароварщики, весьма интересно.
Диалог, где юзер может настроить периодичность проверки или отключить её.
Проверка (по расписанию) наличия апдейта.
Проверка наличия апдейта вручную (из меню).
Если апдейта нет, то молчим, если проверка по расписанию, или, если проверка вручную, говорим юзеру что ни хрена нового у нас пока нет.
Если апдейт есть, показ диалога с инфой (версия, дата релиза, новые фичи, ссылки) + батоны "загрузить" и "обновить". Если юзер тычит "загрузить", то просто сливаем дистрибутив туда, куда он укажет, если тычит "обновить", то сливаем и запускаем инсталер.
Дальше, IMHO, инсталер сам должен быть готов сделать всё как надо (это не задача апдейтера): найти запущенный процесс, прибить его или дернуть юзера, и т.д. и т.п. Это работа автора программы.
Вот собственно все лично мои желания.
Скрипт на сервере, IMHO, плохая идея, т.к. это не гибко. Лучше xml-файл (см. GUP) примерно такого вида (очень упрощенно):
<Cool_proga>
<proga_major_ver>1</proga_major_ver>
<proga_minor_ver>0</proga_minor_ver>
<download_url>урл к дистрибутиву</download_url>
</Cool_proga>
xml может содержать инфу о любом кол-ве прог или их разновидностей. Эта инфа может влючать всё что угодно, например, можно добавить список новых фич или инфу о рекламных акциях, которую апдейтер может выводить в диалог. xml можно менять в любой момент (оставляя нетронутыми старые теги для обратной совместимости). Тут главное заранее хорошо продумать структуру и предусмотреть максимум возможностей, а реально добавлять их можно по необходимости и по мере развития.
Здравствуйте, x64, Вы писали:
x64>пока планирую только — логика checker'а, downloader'а, replacer'а и rebooter'а.
Кстати, чисто технически интересно. Как ты собрался реализовывать обновление исполняемого файла в ОС, которая блокирует файлы запущенных программ, а заодно и весь путь к ним?
Понятно, что речь не идет о серверах, которым нужно уметь обновиться, сохранив все открытые соединения (кстати, APT умеет их обновлять), но все равно неясно.
Здравствуйте, xfruit, Вы писали:
X>Идея совершенно не в том чтобы тащить что-то со своим приложением, идея как раз в том, чтобы вобще ничего не тащить. Идеальным вариантом был бы системный сервис поставляемый компанией Майкрософт и встроенный в ОС. Я очень рад, что такое есть в Windows Vista (если верить посту выше). Уверен что и в следующих ОС это уже будет как правило, дабы избавить разработчика от ненужно гемора, а пользователя от различных вариантов апдэйтов различных приложений (у некоторых они на столько непродуманны, что необходимость в универсальном способе просто становится очевидной). Если у кого-то остался вопрос "Зачем нужна универсальная система?", отвечаю "Затем чтобы больше никогда не возникало желания изобретать очередной бесполезный велосипед и тратить своё время".
Хорошая мысль.
Только не в следующих, а в предыдущих.
APT был выпущен 10 лет назад, заменив dselect, который был включен в состав dpkg в 1995 г.
Т. е., в иных ОС централизованное обновление работает уже 13 лет как.
Давайте все вместе по-быстрому устроим виндекапец, и наступит рай для разработчиков! :-)
В общем, я понял. Только вот господа, а не кажется ли вам, что UI и движок следует разделить? И более того, не кажется ли вам, что движок должен быть написан автором движка, а UI должен быть написан автором продукта? И ещё более того, не кажется ли вам абсурдным, что UI стал бы писать не автор продукта?
Короче, я пока вижу себя автором движка и не более того.
RO>Кстати, чисто технически интересно. Как ты собрался реализовывать обновление исполняемого файла в ОС, которая блокирует файлы запущенных программ, а заодно и весь путь к ним?
Не думал об этом. А после того, как реализую, — писать об этом не стану, ага. Да здравствует режим Билли!
RO>Понятно, что речь не идет о серверах, которым нужно уметь обновиться, сохранив все открытые соединения (кстати, APT умеет их обновлять), но все равно неясно.
На серверах, кстати, начиная с Windows Server 2003 SP1, был введён в строй hot-patching, что позволяет обновляться на лету, с сохранением всех открытых соединений и т.п.
