Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
Здравствуйте, x64, Вы писали:
x64>Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
Портируй лучше APT. Все будут рады (кроме Шеридана).
RO>Портируй лучше APT. Все будут рады (кроме Шеридана).
Ну ты б хоть ссылку дал, я ж вам не линуксоид какой-нибудь, ага. Если ты имеешь в виду Advanced Packaging Tool, то боюсь что вряд ли это будет мне интересно. Да я, честно говоря, вообще не очень люблю что-то повторять, чай не китайцы мы, своя голова есть.
Здравствуйте, x64, Вы писали:
x64>Если ты имеешь в виду Advanced Packaging Tool, то боюсь что вряд ли это будет мне интересно. Да я, честно говоря, вообще не очень люблю что-то повторять, чай не китайцы мы, своя голова есть.
Ты как раз собрался повторить то, что давно уже сделано, но явно намереваешься наступить на давно изученные грабли. Толку-то от обновлялки, которая работает только с одной данной программой?
RO>Ты как раз собрался повторить то, что давно уже сделано, но явно намереваешься наступить на давно изученные грабли.
Ну вот зачем ты чушь-то откровенную говоришь? В Windows нет стандартного механизма автообновления приложений. Сторонние разработки — да, наверняка есть. Если знаешь такие — дай ссылку.
RO>Толку-то от обновлялки, которая работает только с одной данной программой?
Это что ещё за глупость #2? Толк вполне понятный, думаю, — увеличение скорости разработки продукта, т.е. прямая выгода непосредственно для разработчика. Подключаешь DLL к проекту и вызываешь время от времени соответствующие функции типа "DownloadAndReplaceFiles(...)" — быстро и просто.
Что касается обновлялки, которая встраивается в систему и предоставляет интерфейс для автообновлений нескольким приложениям... Ну я честно говоря, не вижу в чём смысл конкретно для одного отдельно взятого разработчика aka шароварщика. Вот распиши здесь плюсы, которые получит разработчик, тогда я подумаю над твоим предложением. А чего попусту болтать-то.
Здравствуйте, x64, Вы писали:
x64>Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
Мне надо!
Обновления выходят довольно часто. Автообновление не прикручено, каждый раз пишут письма: "шеф, все пропало!". Уже даже позывы самому написать...
Ну если хоть один есть — значит всяко не зря. Ты только распиши, какая схема (aka алгоритм) применения автообновления у тебя предполагается?
Z>Обновления выходят довольно часто.
Расскажи пару слов об архитектуре софта (мне для статистики). Напиши своими словами и вот такую анкетку можешь ещё заполнить:
1. С какими правами могут запускаться исполняемые модули продукта (перечислить) ?
2. Предусматривает ли архитектура продукта реализацию NT-служб, драйверов (да/нет) ?
3. В каких папках обычно располагаются файлы после установки (перечислить) ?
4. Обновлённые файлы должны скачиваться с Web-сайта, извлекаться из локального архива или располагаться открыто в локальной папке (перечислить) ?
5. Каково примерное кол-во потенциально обновляющихся файлов (число) ?
6. Приложение Win32, .Net, Java или что-то другое (подчеркнуть) ?
7. Если приложение не Win32, то допустимо ли использовать в нём Win32-модули (да/нет) ?
8. Как часто может происходить обновление (период) ?
9. Могут ли потенциально обновляемые файлы быть жёстко заблокированы (без возможности удаления/переименования/etc.) на момент обновления (да/нет) ?
Z>З.Ы. Могу быть тестером активным
x64>В Windows нет стандартного механизма автообновления приложений.
В висте есть. Там в настройках автообновлений можно указать приложения, который могут обновляться через этот механизм. Соответственно, видимо приложение должно уметь это делать "как надо".
Хм, не знал. Дай ссылку на API Reference.
TC>Там в настройках автообновлений можно указать приложения, который могут обновляться через этот механизм. Соответственно, видимо приложение должно уметь это делать "как надо".
Скорее всего там всё завязано на MSI и пакеты обновлений. Что-то мне не очень нравится такая идея, ибо на практике сам процесс обновления может быть настолько простым, что поднимать ради него весь MSI API или изучать пакеты типа InstallShield покажется слишком трудозатратно, ежели там всего-то один файлик заменить или добавить, например.
JID: x64j@jabber.ru
Re[3]: Востребованность автообновления
От:
Аноним
Дата:
28.09.08 15:27
Оценка:
Здравствуйте, x64, Вы писали:
Z>>Мне надо!
x64>Ну если хоть один есть — значит всяко не зря. Ты только распиши, какая схема (aka алгоритм) применения автообновления у тебя предполагается?
Спасибо, посмотрю. Хочется реализовать что-то легковесное с одной стороны, но при этом чтобы фичей побольше было. Посмотрим, получится ли.
JID: x64j@jabber.ru
Re[5]: Востребованность автообновления
От:
Аноним
Дата:
28.09.08 15:56
Оценка:
Здравствуйте, x64, Вы писали:
x64>Спасибо, посмотрю. Хочется реализовать что-то легковесное с одной стороны, но при этом чтобы фичей побольше было. Посмотрим, получится ли.
кроме этого автообновление есть в CreateInstall и за последний год было два человека который писали updeter (поищите поиском здесь) один из них дал мне исходник когда я попросил.
я интересовался updaterом когда писал для себя
из фич которых я хотел бы видеть в updater
возможность оновлять запущенное приложение (хотя бы при следующем рестарте win)
возможность простого обновления нескольких файлов (на сервере файл со списком файлов которые надо обновить)
обязательно поддержка proxy
задание время и дату когда проверять обновления (или при каждом старте программы)
А>из фич которых я хотел бы видеть в updater А>возможность оновлять запущенное приложение (хотя бы при следующем рестарте win) А>возможность простого обновления нескольких файлов (на сервере файл со списком файлов которые надо обновить) А>обязательно поддержка proxy А>задание время и дату когда проверять обновления (или при каждом старте программы)
Ну да, это самое основное и это я реализую в первую очередь.
.
x64>Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
Да не нужна библиотечка! Это уже вчерашний день. Нужно иметь системный сервис, в котором я могу зарегистрировать свое приложение и забыть об апдэйтах навсегда.
Технически это, например, COM-объект в системе с одним методом:
RegisterAppForUpdate(AppName, UpdateLink, UpdateCheckInterval, KillMessage)
Все!
Это означает, что есть некоторый общий системный стек приложений зарегистрированных в некотором сервисе апдейта приложений. Я могу при первой инсталляции своего приложения зарегистрировать его в этом системном стеке апдейтов и забыть об апдейтах навсегда! Что должен делать этот сервис? Он должен с указанным интервалом проверять по указанной ссылке новые версии, уведомлять пользователя о том что такое-то приложение может быть обновлено до такой-то версии, загружать приложение на машину пользователя, отправлять приложению указанное сообщение об уведомлении, и когда приложение закрыто обновлять его файлы в соответствии со скриптом который будет загружен с сервера.
Возможно я описал как-то сыровато, но идея примерно такая.
P.S. И конечно же этот сервис должен быть бесплатным, а уж как на нем заработать думайте сами
X>Возможно я описал как-то сыровато, но идея примерно такая.
Да уж, кривее некуда, хотя суть понятна. Только ты уже не первый, вон RO тоже пытается мне сказать, что выделенная для обновления служба лучше DLL, загружаемой в каждое приложение. Внимание, вопрос — а чем лучше-то?
X>P.S. И конечно же этот сервис должен быть бесплатным, а уж как на нем заработать думайте сами
Вот знаешь, поток сознания мне твой понятен, но вот эта фраза отбивает весь энтузиазм. Тебе оно надо?
> Да не нужна библиотечка! Это уже вчерашний день. Нужно иметь системный сервис, в котором я могу зарегистрировать свое приложение и забыть об апдэйтах навсегда.
А почему нельзя иметь 2 имплементации: как DLL, и как COM? Причем COM-объект вполне может использовать ту же DLL!?! Есть у меня одна софтина, причем мелкая и обновляться может достаточно часто. Весит все вместе!!! (включая ридми и прочий сопутствующий хлам) — 60 кило... Я что буду туда еще COM какой-то прикручать только из апдейта? Дык вряд ли...
Имхо, а подход COM+DLL вполне: и волки сыты, и овцы целы?
Сервис нафиг не нужен. Зачем разбрасывать по системе какие-то ком-объекты, гадить в реестр и т.п. В 99,9999% случаев этим сервисом будет пользоваться только та прога, которая его и притащила. Или вы думаете, что всё прогрессивное шароварное человечество тут же на него перескочет? Исключено. Апдейтер должен быть маленький и негадючий.
Зачем для проги в 60кБ апдейтер вообще? На крайняк дернуть исходник из опен-сорса ( ну типа творчески переработать ), который проверяет файлик на сервере с актуальной версией и долбит юзера, а юзер уже пусть сам парится. Там кода будет на 500 байт.
С год назад рыл на предмет прикручивания. Толком ничего не нашёл — пришлось писать самому. Искал фришный или опенсорс, но только MFC или чистый апи. Нарыл либо блотварь по два метра с нафиг-ненужными мега функциями, либо простые проверяльщики.
Здравствуйте, x64, Вы писали:
x64>Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
Может конечно для каких-то определенных классов приложений это и необходимо. Только обычной шароваре, не антивирусу/файрволу/еще какой критичной штуке, на мой взгляд автообновляться скорее вредно чем полезно. С точки зрения безопасности например отстойно, и я как пользователь 100% отключу такую функцию для приложений всех малоизвестных производителей. Мало ли чего им там в голову взбредет автообновить. Если софтина к интернету не имеет отношения, то тем более нечего ей туда лазить, да еще чего-то менять в системе в автоматическом режиме. Одно дело когда просто выводится диалог что типа — а вот новая версия кстати появилась, поди скачай если время есть. И совсем другое если оно само начнет жить своей жизнью, на фиг надо.
S>С год назад рыл на предмет прикручивания. Толком ничего не нашёл — пришлось писать самому.
Ну дык расскажи, какой функционал тебе нужен был? Мне, сам понимаешь, как автору_будущего_автоапдейтера_которым_будут_пользоваться_все_шароварщики, весьма интересно.
Здравствуйте, Sharewarkin, Вы писали:
S>Сразу говорю — всё IMHO.
Поддержу своим IMHO
Сколько раз уже убеждаюсь что "все гениальное просто". Если делать что-то супер-пупер универсальное, то получится такой монстр...
Так же и с автоапдейтом. По большому счету все что должна уметь автообновлялка это ломануться на сервер, при наличии новой версии скачать инсталятор, запустить его с нужными ключами, просечь необходимость перезагрузки и перегрузить компьютер, если пользователь согласится. Всё! Весь остальной функционал делает тот самый инсталятор. Так или иначе инсталятор все равно нужно делать. Ну а какой инсталятор подсовывать автообновлялке это уже вопрос личных предпочтений. Я предпочитаю тот-же, что качается через сайт.
Собственно все вот и вся идея. Ну а периодичность проверок можно и в шедулер винды запихать
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, что позволяет обновляться на лету, с сохранением всех открытых соединений и т.п.
.
x64>Насколько среди шароварщиков распространено автообновление продуктов? Подумываю над реализацией подобной универсальной библиотеки-обёртки в виде динамической Win32 DLL. Распространяться будет как Freeware. Стоит ли?
Да, стоит.
И вот ещё сабж косвенный такой возник.
Все пользователи делятся на 2 группы — те, которые любят и используют автообновления и те которые нет.
Дык вот, подумал я сшас сделать себе про топик-сабж:2 и не только общие настройки для всех своих приложений.
К примеру.
Грузит юзер программу номер раз: ставит её, она его спрашивает: хотите автообновление? По умолчанию — хочу. Он грит: нет. Прога записывает его мнение в общую кучу настроек.
Грузит программу номер два, ставит её, она смотрит в настройки и говорит: хотите автообновление? По умолчанию — (уже)не хочу. Ну и так далее.
Здравствуйте, x64, Вы писали:
x64>В общем, я понял. Только вот господа, а не кажется ли вам, что UI и движок следует разделить? И более того, не кажется ли вам, что движок должен быть написан автором движка, а UI должен быть написан автором продукта? И ещё более того, не кажется ли вам абсурдным, что UI стал бы писать не автор продукта?
Так интерфейс в этом всем деле, как мне видится, самая сложная часть. Мало кто переделывает интерфейс инсталяторов
Я уже тоже так думаю.
CEM>К примеру. CEM>Грузит юзер программу номер раз: ставит её, она его спрашивает: хотите автообновление? По умолчанию — хочу. Он грит: нет. Прога записывает его мнение в общую кучу настроек. CEM>Грузит программу номер два, ставит её, она смотрит в настройки и говорит: хотите автообновление? По умолчанию — (уже)не хочу. Ну и так далее.
Ну ты опять говоришь про некую отдельную службу-мониторилку обновлений. Я считаю это злом, ибо
Различных программных продуктов со своей спецификой — много, очень много. Чтобы такая-служба мониторилка реально работала и была удобной в использовании, она должна быть распространена среди разработчиков софта и они должны писать соответственно-ориентированные продукты. Здесь есть две проблемы:
1. Во-первых, кто будет заниматься распространением и продвижением? Кто здесь самый пробитый альтруист с кучей времени?
2. Во-вторых, даже при решении первой проблемы, такие гиганты как Adobe или Sun с усмешкой пойдут своим путём дальше, и большинство более-менее крупных компаний — аналогично.
Здравствуйте, x64, Вы писали:
CEM>>Да, стоит.
x64>Я уже тоже так думаю.
поскипано..
x64>Так что смысла не вижу, нет, не вижу...
Слушай, я вот все никак понять не могу, у тебя цель то вобще какая? Если тебе внетерпеж ченить пописать, то тебе какая разница кто будет продвижением заниматься и зарабатывать? Если хочешь заработать денег, то думай шире...
Здравствуйте, x64, Вы писали:
x64>Так что смысла не вижу, нет, не вижу...
Ну, не знаю, помницца... на прошлой работе я за быстро написал ftp-опрашивалку файла с версией своей софтины.
А не! Даже не так! Вспомнил как: она лезла на сервер, смотрела версию, потом спрашивала у юзера "хотите проапдейтиться?" если юзер хотел, она сама себя загружала, перезаписывала и перезапускала.... Блин... как прикольно я придумывал и делал раньше... куда чё деётся...
Здравствуйте, CEMb, Вы писали:
CEM>Здравствуйте, x64, Вы писали:
x64>>Так что смысла не вижу, нет, не вижу...
CEM>Ну, не знаю, помницца... на прошлой работе я за быстро написал ftp-опрашивалку файла с версией своей софтины.
та все наверное такое писали. я вообще всё это в длл выкидывал. из нее только одна процедура вызывалась. и уже и интерфейс строила, и по сайтам лазила, и все что надо обновляла и даже бегунок закачки рисовала
а, вспомнил — в стандарте xml файла на сайте с обновлениями даже описание к версии поддерживалось, и вызовы скриптов, и обовление через версию, и подряд по версиям.
в общем дофига всего. до чего лень довела. софта было много моего на фирме, и компов много, на все не набегаешься
