Те же Хабр и MediaWiki не используют List-ID, но ладно — есть ли внятное описание, как реагируют на наличие List-ID почтовые сервисы, хотя бы тот же Gmail? Учитывается ли он в алгоритме работы кнопки «Отписаться» и влияет ли на последующую вероятность попадания в спам? На всякий случай уточню, что меня как автора рассылок интересует не сферический RFC в вакууме, а реальное поведение реальных почтовых сервисов
Про идентификацию разных рассылок в RFC 2369 я тоже ничего не заметил. Видимо, подразумевается, что рассылка идентифицируется по адресу отправителя — это нормально для mailing lists (для которых эти RFC, собственно, и написаны), но вот на современных сайтах такое встречается, мягко говоря, нечасто
Для современных сайтов имеет значение разделение в первую очередь по сущностям, на которые выполняется подписка — у того же Хабра это, например, посты, а на MediaWiki это, например, статьи. Наверное, они могли бы использовать адреса вида «noreply+new-comment-in-post-766016@habr.com» или «wiki+new-edit-in-FIVB-Volleyball-Womens-Intercontinental-Olympic-Qualification-Tournaments@wikimedia.org» для каждой из тысяч-миллионов сущностей — но что-то мне подсказывает, что от таких адресов пользователи взвоют ещё сильнее, чем от отсутствия нативной кнопки «Отписаться»
Тот же Хабр шлёт все уведомления с одного адреса. Гитхаб, например, тоже с одного. Ещё из того, что есть в моей почте: Steam — с одного, хостинги — с одного, MediaWiki — с одного, Crowdin — с одного. Наверное, если взять почти любой сайт — он будет слать всё с одного адреса.
И это написано в блоке «other methods» после блока про List-Unsubscribe. Должен ли я это интепретировать как то, что сам гугл рекомендует избегать использования List-Unsubscribe?
Не увидел там ничего про ситуацию с сотней рассылок. Зато вижу подтверждение своих страшилок:
he URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that the unsubscription process can complete automatically.
Что ещё раз говорит о том, что предлагаемую вами страницу сделать технически невозможно и что использование List-Unsubscribe несёт вред.
Что такое «the list»? Какой конкретно «the list», если их сотня?
Или ещё более страшный случай — пользователь отписался, а потом подписался снова. Ощущается как гарантированный способ улететь в спам... По вот таким вот причинам я на данный момент принципиально игнорирую List-Unsubscribe (хотя был бы рад добавить, если бы имел внятное представление, как он должен работать)
Когда-то давно тут на Хабре видел страшилки, что почтовый сервис (как минимум mail.ru) переходит по ссылке сам в фоне, и никакой страницы в принципе быть не может
Как автора рассылок меня давно беспокоит вопрос — отписаться от чего?
Если пользователь подписался на сто моих рассылок и на одной из них нажимает «Отписаться» — я должен отписать его от одной конкретной рассылки или от всей сотни сразу?
Если я отпишу пользователя от одной рассылки, но продолжу присылать остальные девяносто девять — забанят ли меня как спамера? А если я отпишу от всей сотни рассылок — поймёт ли пользователь, что он реально отписался именно от всей сотни?
Как пользователь может понять, от чего конкретно он отписывается, если на кнопке «Отписаться» этого не написано?
Если какое-то железо официально не поддерживается, значит есть риск, что в какой-то момент оно может стать реально дропнуто, и эти ваши параметры тут ни при чём. Если бы я пользовался виндой, мне бы не очень хотелось, чтобы какое-нибудь новое обновление внезапно задействовало бы неподдерживаемые моим процессором инструкции и валило бы систему в синий экран, например
Похоже, починилось? В последние несколько дней расхождений в счётчиках не наблюдаю
UPD: а хотя не совсем, после отправки своего комментария увидел «162+2», хотя новых комментариев нет. Но по крайней мере это не так страшно, как отсутствие уведомления о реально существующих новых комментариях
Вот да, буквально пару недель назад я умудрился перепутать два инкрементных идентификатора с всего пятью цифрами)
В этом плане я наоборот вижу у UUID преимущества:
Если переписывать UUID руками, то при опечатке с высокой вероятностью получится несуществующий id, а значит ничего страшного не случится (а при опечатке в числовом инкрементном id можно, например, случайно удалить не тот объект)
Длинность UUID заставляет его не переписывать, а по возможности копировать, и при копировании нетрудно проверить, что копирование выполняется из правильного места
Если случайно скопировать id из другой сущности, то при попытке применить его к нужной сущности этот id опять же окажется скорее всего несуществующим (в то время как условный инкрементый id=1 будет существовать у всех сущностей, и это опять же создаёт риск случайно удалить не то)
(Впрочем, всё то же самое применимо и к Snowflake/Sonyflake, только вероятности немножко другие)
Те же Хабр и MediaWiki не используют List-ID, но ладно — есть ли внятное описание, как реагируют на наличие List-ID почтовые сервисы, хотя бы тот же Gmail? Учитывается ли он в алгоритме работы кнопки «Отписаться» и влияет ли на последующую вероятность попадания в спам? На всякий случай уточню, что меня как автора рассылок интересует не сферический RFC в вакууме, а реальное поведение реальных почтовых сервисов
Про идентификацию разных рассылок в RFC 2369 я тоже ничего не заметил. Видимо, подразумевается, что рассылка идентифицируется по адресу отправителя — это нормально для mailing lists (для которых эти RFC, собственно, и написаны), но вот на современных сайтах такое встречается, мягко говоря, нечасто
Для современных сайтов имеет значение разделение в первую очередь по сущностям, на которые выполняется подписка — у того же Хабра это, например, посты, а на MediaWiki это, например, статьи. Наверное, они могли бы использовать адреса вида «noreply+new-comment-in-post-766016@habr.com» или «wiki+new-edit-in-FIVB-Volleyball-Womens-Intercontinental-Olympic-Qualification-Tournaments@wikimedia.org» для каждой из тысяч-миллионов сущностей — но что-то мне подсказывает, что от таких адресов пользователи взвоют ещё сильнее, чем от отсутствия нативной кнопки «Отписаться»
Тот же Хабр шлёт все уведомления с одного адреса. Гитхаб, например, тоже с одного. Ещё из того, что есть в моей почте: Steam — с одного, хостинги — с одного, MediaWiki — с одного, Crowdin — с одного. Наверное, если взять почти любой сайт — он будет слать всё с одного адреса.
Все делают рассылки неправильно?
И это написано в блоке «other methods» после блока про List-Unsubscribe. Должен ли я это интепретировать как то, что сам гугл рекомендует избегать использования List-Unsubscribe?
Не увидел там ничего про ситуацию с сотней рассылок. Зато вижу подтверждение своих страшилок:
Что ещё раз говорит о том, что предлагаемую вами страницу сделать технически невозможно и что использование List-Unsubscribe несёт вред.
Что такое «the list»? Какой конкретно «the list», если их сотня?
Или ещё более страшный случай — пользователь отписался, а потом подписался снова. Ощущается как гарантированный способ улететь в спам... По вот таким вот причинам я на данный момент принципиально игнорирую List-Unsubscribe (хотя был бы рад добавить, если бы имел внятное представление, как он должен работать)
Когда-то давно тут на Хабре видел страшилки, что почтовый сервис (как минимум mail.ru) переходит по ссылке сам в фоне, и никакой страницы в принципе быть не может
Как автора рассылок меня давно беспокоит вопрос — отписаться от чего?
Если пользователь подписался на сто моих рассылок и на одной из них нажимает «Отписаться» — я должен отписать его от одной конкретной рассылки или от всей сотни сразу?
Если я отпишу пользователя от одной рассылки, но продолжу присылать остальные девяносто девять — забанят ли меня как спамера? А если я отпишу от всей сотни рассылок — поймёт ли пользователь, что он реально отписался именно от всей сотни?
Как пользователь может понять, от чего конкретно он отписывается, если на кнопке «Отписаться» этого не написано?
Если какое-то железо официально не поддерживается, значит есть риск, что в какой-то момент оно может стать реально дропнуто, и эти ваши параметры тут ни при чём. Если бы я пользовался виндой, мне бы не очень хотелось, чтобы какое-нибудь новое обновление внезапно задействовало бы неподдерживаемые моим процессором инструкции и валило бы систему в синий экран, например
За примером можно сходить к Rust, которому edition'ы позволяют развиваться без поломки обратной совместимости
В документации всё есть (в частности опции hls_playlist и dash_segment_type)
Похоже, починилось? В последние несколько дней расхождений в счётчиках не наблюдаю
UPD: а хотя не совсем, после отправки своего комментария увидел «162+2», хотя новых комментариев нет. Но по крайней мере это не так страшно, как отсутствие уведомления о реально существующих новых комментариях
Окей, до вашего комментария не слышал ¯\_(ツ)_/¯
Эм, можно пример сервера из «середины 90-х» с этим языком?
Мне не нужно, а вот Kelbon'у видимо зачем-то нужно )
А Cursor, как я понимаю, до итераторов из C++ всё равно не дотягивает
А как взять следующий объект после
itили предыдущий перед ним?Однако по статистике «Одноклассников» у 66% юзеров это не прокатывает
Вот да, буквально пару недель назад я умудрился перепутать два инкрементных идентификатора с всего пятью цифрами)
В этом плане я наоборот вижу у UUID преимущества:
Если переписывать UUID руками, то при опечатке с высокой вероятностью получится несуществующий id, а значит ничего страшного не случится (а при опечатке в числовом инкрементном id можно, например, случайно удалить не тот объект)
Длинность UUID заставляет его не переписывать, а по возможности копировать, и при копировании нетрудно проверить, что копирование выполняется из правильного места
Если случайно скопировать id из другой сущности, то при попытке применить его к нужной сущности этот id опять же окажется скорее всего несуществующим (в то время как условный инкрементый id=1 будет существовать у всех сущностей, и это опять же создаёт риск случайно удалить не то)
(Впрочем, всё то же самое применимо и к Snowflake/Sonyflake, только вероятности немножко другие)
С учётом того, как делаются современные фронтенды, предположение про кэш является чушью