Если не секрет кто какой подход использует для проверки выхода новых версий из настольных приложений?

Есть ли какой-нибудь более-менее единый стандарт на формат фида для уведомления пользователя о наличии новой версии (XML, JSON и т.п.)?

Подойдет ли для этой цели обычный RSS?

Здравствуйте, baranovda, Вы писали:

B>Если не секрет кто какой подход использует для проверки выхода новых версий из настольных приложений?
Скачиваем XML-файл, вытаскиваем инфу, анализируем — показываем пользователю.

B>Есть ли какой-нибудь более-менее единый стандарт на формат фида для уведомления пользователя о наличии новой версии (XML, JSON и т.п.)?
Вроде как нет. Ну разве что PAD. Хотя, имхо, это из пушки по воробьям.

B>Подойдет ли для этой цели обычный RSS?
Точно уж нет.

Здравствуйте, Carc, Вы писали:

C>Здравствуйте, baranovda, Вы писали:

B>>Если не секрет кто какой подход использует для проверки выхода новых версий из настольных приложений?
C>Скачиваем XML-файл, вытаскиваем инфу, анализируем — показываем пользователю.

RSS и есть XML. Я к тому, что и RSS предназначен для уведомлений (через броузер), и обновляльный самодельный формат XML тоже для уведомлений (программно). Зачем держать два?

B>>Есть ли какой-нибудь более-менее единый стандарт на формат фида для уведомления пользователя о наличии новой версии (XML, JSON и т.п.)?
C>Вроде как нет. Ну разве что PAD. Хотя, имхо, это из пушки по воробьям.

Спасибо, посмотрю

B>>Подойдет ли для этой цели обычный RSS?
C>Точно уж нет.

А почему RSS категорически нет? А если все-таки его расширить своими элементами?

Здравствуйте, baranovda, Вы писали:

B>Если не секрет кто какой подход использует для проверки выхода новых версий из настольных приложений?

B>Есть ли какой-нибудь более-менее единый стандарт на формат фида для уведомления пользователя о наличии новой версии (XML, JSON и т.п.)?

B>Подойдет ли для этой цели обычный RSS?

В Unix-системах — репозиторий.
Стандарта в Вензоуз нет. Каждый извращается, как может, вешает безумные демоны в фон, которые скачивают что покажется нужным разработчику. Планировщик использовать нельзя — нет гарантии, что он включен и будет включен. Перефразируя Малышеву: "60 процессов в диспетчере задач — это норма".

Здравствуйте, sharez, Вы писали:

S>В Unix-системах — репозиторий.
S>Стандарта в Вензоуз нет. Каждый извращается, как может, вешает безумные демоны в фон, которые скачивают что покажется нужным разработчику. Планировщик использовать нельзя — нет гарантии, что он включен и будет включен. Перефразируя Малышеву: "60 процессов в диспетчере задач — это норма".

Для асинхронного транспорта в Windows есть BITS, для инсталляции MSI, но речь не о них репозиториев действительно нет и это удручает

Здравствуйте, baranovda, Вы писали:

B>Здравствуйте, sharez, Вы писали:

S>>В Unix-системах — репозиторий.
S>>Стандарта в Вензоуз нет. Каждый извращается, как может, вешает безумные демоны в фон, которые скачивают что покажется нужным разработчику. Планировщик использовать нельзя — нет гарантии, что он включен и будет включен. Перефразируя Малышеву: "60 процессов в диспетчере задач — это норма".

B>Для асинхронного транспорта в Windows есть BITS, для инсталляции MSI, но речь не о них репозиториев действительно нет и это удручает

Если не лукавить, то этот MSI с точки зрения автоматизации и универсализации — как мертвому припара.
Да и речь скорее не в способе упаковки или транспорте, а в втроенном в ОС механизме обновления, замены, патчинга или чего-то такого. Его нет.

B>RSS и есть XML. Я к тому, что и RSS предназначен для уведомлений (через броузер), и обновляльный самодельный формат XML тоже для уведомлений (программно). Зачем держать два?
Для проверки новых версий может понадобиться куча специфической инфы, вроде номера версий, дата релиза, платформа, битность... Ну и где это в формате RSS стандартизовано?

B>>>Есть ли какой-нибудь более-менее единый стандарт на формат фида для уведомления пользователя о наличии новой версии (XML, JSON и т.п.)?
C>>Вроде как нет. Ну разве что PAD. Хотя, имхо, это из пушки по воробьям.
B>Спасибо, посмотрю

PAD можно, но я бы не закладывался. Задача проверки обновлений весьма специфична. Может понадобиться в инфу в XML добавить свои поля. Тогда это будет уже не PAD-файл. Тогда нафиг он вообще такое мутированный нужен?

B>>>Подойдет ли для этой цели обычный RSS?
C>>Точно уж нет.

B>А почему RSS категорически нет? А если все-таки его расширить своими элементами?
Почему Выше. А зачем расширять? Совершенство это когда нечего убрать, а не нечего добавить (ц).

Здравствуйте, baranovda, Вы писали:

B>Если не секрет кто какой подход использует для проверки выхода новых версий из настольных приложений?

Лежит себе файлик на сервере, показывающий номер билда. Софт его сравнивает со своим, все.

Здравствуйте, Carc, Вы писали:

C>Почему Выше. А зачем расширять? Совершенство это когда нечего убрать, а не нечего добавить (ц).

А тут вот чего пишут

http://stackoverflow.com/questions/6973434/extending-rss-format-with-more-fields

RSS 2.0 adds that capability, following a simple rule. A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace."

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

Здравствуйте, baranovda, Вы писали:

B>Здравствуйте, Carc, Вы писали:

C>>Почему Выше. А зачем расширять? Совершенство это когда нечего убрать, а не нечего добавить (ц).

B>А тут вот чего пишут

B>http://stackoverflow.com/questions/6973434/extending-rss-format-with-more-fields

B>

B>RSS 2.0 adds that capability, following a simple rule. A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace."

B>Не подумай что я спорю ради спора, просто с PAD я незнаком, свой формат писать неохота, а насчет RSS принять взвешенное решение самостоятельно чота не могу. Но RSS на сайтике мне нужен и так, вот я и прикидываю, можно ли присобачить его и интересуюсь, насколько это решение будет каноничнымъ

Галимым оно будет, скорее всего, такое решение. И вот почему.
Что по сути RSS — это лента новостей, так? Кто ее читает? Да кто угодно? От конкурентов и пользователей соседних на сайте продуктов, да журналюг и вообще проходящих мимо. Соответственно аудитория может быть совершенно разноликой.

Что есть проверка обновлений. Именно проверка, а не сразу установка (хотя и это тоже, но уже как дополнение). В проверке должно быть что? В инфе для проверки должны быть какие-то специфичные поля: номера бильдов, поддержка платформ, битность, халявность обновлений для зареганных юзеров (коли обновления случаются платные), даты релизов и все такое прочее. Т.е. информация крайне специфичная и четко заточенная под конкретные нужды софта.

Но главное: кто будет получать инфу об обновлениях? Дык исключительно пользователи софта. Уже пользователи, а не все подряд всяко разные. Т.е. аудитория сильно таргетированная, это уже исключительно наши. В такую инфу можно добавить и еще чего-нить, я имею ввиду сам XML. Ссылки на какие-нить последние статьи, инфу о скидках (причем например для зареганных юзеров), еще что-то.

Вы уверены что, стоит мешать все эти абсолютно разные информационные блюда в одну тарелку? Я вот что-то сомневаюсь...

Отдельный XML, просто с инфой о номерах версий это очень просто. Начать можно с малого: номера версий и только, потом можно наращивать другие поля. Сам XML-файл будет маленьким и достаточно простым. Значительно проще его и редактировать, и контроллировать, и изменять формат.

В мешанине с RSS рано или поздно, как в большой свалке новостной инфы, в момент Икс будет совершена ошибка с номером версии. И фиг заметите, ибо скорее всего такая фигня случится, когда будете редактировать новости. Кто ж заметит, что номер инфы о версиях случайно сбился. Так бывает. А оно нам надо? Поредактировал я RSS в своей жизни. И без мешанины-то, исключительно только с новостями сколько раз лажал. От тоски да безысходности написал аж свой собственный редактор RSS.

А в чем сложность разработки собственного формата XML с номерами версий? Там полей-то, особенно поначалу, будет две-три штуки, ну максимум три с половиной. В моих последних вариантах в XML только 4 поля: номер версии, две URL`а на версию с инсталлером и версию портабельную, и ссылка на полный список изменений на сайте. Все остальное: размеры файлов для скачки, даты релизов вытаскиваются модулем проверки обновлений через HTTP-запросы непосредственно с сайта.

Что имею: полнейшую гибкость — формат мой. Полный контроль — вплоть до логов обращений к отдельному XML-файлу с инфой о версии. Заметьте: статистика вай какая интересная: кто, когда, куда, откуда и чего хотел обновить (страны, языки, настройки, программы и чего только туда не пихнешь). Легкая расширяемость такого формата. К примеру: в моем XML-есть ссылка на портабельную версию на сайте (ZIP со всем барахлом, и ничего лишнего). Прикрутить автоматическую установку такого обновления это как два пальца об асфальт — 2 часа работы (чего там писать то: скачать ZIP, распаковать его, и перезаписать самое себя этими же распакованными файлами). PS: люди давно просили, да все руки не доходят сделать.

PS: понятное дело XML содержит только инфу по делу, когда и кому ее показывать, в каком виде визаулизировать — это уже вопросы десктопной реализации. Можно HTML сгененить по шаблону, используя инфу из XML и красивенько ее пользователю показать — тут можно и скидки за компанию предложить, и объявление какое-нить по делу крутануть и все остальное.

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

Здравствуйте, Carc, Вы писали:

B>>Не подумай что я спорю ради спора, просто с PAD я незнаком, свой формат писать неохота, а насчет RSS принять взвешенное решение самостоятельно чота не могу. Но RSS на сайтике мне нужен и так, вот я и прикидываю, можно ли присобачить его и интересуюсь, насколько это решение будет каноничнымъ

C>Галимым оно будет, скорее всего, такое решение. И вот почему.

OK, убедил

Здравствуйте, baranovda, Вы писали:

B>Здравствуйте, Carc, Вы писали:

B>>>Не подумай что я спорю ради спора, просто с PAD я незнаком, свой формат писать неохота, а насчет RSS принять взвешенное решение самостоятельно чота не могу. Но RSS на сайтике мне нужен и так, вот я и прикидываю, можно ли присобачить его и интересуюсь, насколько это решение будет каноничнымъ

C>>Галимым оно будет, скорее всего, такое решение. И вот почему.

B>OK, убедил
PS: забыл сказать
1) когда еще и отдельный XML с инфой об обновлении легко статистику получить по нему. В RSS получим мешанину, а не статистику. Все в кучу — и читатели новостей, и обновляльщики.

2) Запрос к XML можно гнать через скрипт на сервере. Он много чего полезного вытащит сам (IP, языки, платформы). Но и свои переменные не грех добавить. Уф, ладно, каюсь, грех , но человек существо грешное и я не исключение.
У меня парочка мультиязычных версий (бинарник один с аглицким, остальные языки сбоку файликами лежат) — ессесна мне любопытно, кто какой язык UI ставит себе. Чего б и не передать в запрос на обновления? Ну да мысль ясна. Только наглеть никогд ни стоит. Ничего личного передавать не стоит. Репутация зарабатывается годами, зато теряется в 15 минут. Стоит подумать об ощущениях.
PS: кто-то как-то в форуме у меня спрашивали, "гошинька, роднинький, а чой-то это за параметер вот это вот в запросе на обновление". Так что шило в мешке не утаишь. Правда, и объяснил нормально — что это означает наличие такой-то там настройки в этой софтине, ибо я никак не мог решить включать ее по умолчанию или нет. И всё. Человек успокоился — ибо репутация и так была вполне на высоте, а ничего секретного и правда на сервер не отправлялось.

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