"Отправка уведомлений с сервера в клиентское приложение"
https://wonderland.v8.1c.ru/blog/otpravka-uvedomleniy-s-servera-v-klientskoe-prilozhenie/

1. :[|||||]:
2. Почему не использовать обычные оповещения (на форму)???
Зачем новая сущность почти такая же?

(1) чтобы обрабатывать уведомления фоновыми заданиями, где нет форм

1С:Сервер взаимодействия идет лесом?)

(3)

(2) Эмм. Какие фоновые задания на клиенте?
Отправка же из серверного фонового на клиента - всегда подразумевает наличие хотя бы одной формы

(5)+ Хотя согласен если можно будет ловить в ОбщийМодульКлиент
Если же нет - это банальное оповещение в форме

интересно что имеется ввиду? если пользователь открыл 2 сеанса, то уведомление придет в конкретный сеанс-получатель или что-то другое?

(9) Логично, зачем Даше под логином Саши сообщение из другого сеанса Саши.

Из статьи непонятно - у клиента будет событие или все также надо чето опрашивать.

То, о чём так долго говорили большевики, свершилось! (только надо немножко подождать)

(11) Ну вроде сначала надо подписаться

МенеджерУведомленийКлиента.ПодключитьОбработчик(Ключ, Обработчик)

потом ждать вызова Обработчик.
Сам вызовется

(11) вот же:

Может так и до лямбд доживём?..

Непонятно, что мешало это сделать 10 лет назад.

(16) религия не позволяла, а теперь вот самим понадобилось

(15) Может еще разрешат код из обычных dll выполнять?

(11) Что значит непонято?
Конечно же будет событие
Иначе это уже и так есть
То есть на сервере что-то закончилось и тут же (тут же — это миллисекунды, а не я даже чаю не успел налить) на клиенте событие
То есть, если ты в одном сеансе в поле выбрал значение 100 и тут же отправил сообщение на сервер, а сервер тут же отправил сообщение на второй сеанс, который по событию напишет в поле значение из первого сеанса, то во втором сеансе на форме в поле значение появится 10 быстрее, чем ты успеешь повернуть шею

Можно не завершая фоновое результат промежуточный возвращать

Ну что, кто первый напишет православный чат на 1С?

(16) А зачем?

Думаю, из очевидного применения только обновление списков по событию, а не каждые x секунд

Ну кстати да, еще (20) конечно же

(22) А зачем "паузу" реализовали? Ведь столько разных шикарных велосипедов написано, даже в типовых.

(20) Можно и сейчас положить во временное хранилище промежуточный результат.

По идее вещь небесполезная. Но как бы за всеми этими бантиками и рюшечками чего-то действительно полезного не запортили...

(25) Это примерно из той же серии

(26) Тут важно не то, что промежуточный, а важно то, что молниеносно получать, а не периодически заглядывать на сервер, нет ли там чего

И это хорошо!

(29) Вряд ли это будет молниеносно. Наверняка будет лаг

Прикрутят хттп пополам, вместо 1.1
Судя по номеру версии стабильные релизы в 26 году ожидаются.

На 89% разработчики типовых использовать это не будут, а придумают свой велосипед на 27 модулей

(31) Не будет
Будет как и в системе взаимодействия
Веб-сокеты

(33) В том-то и дело, что там придумать самому ничего нельзя принципиально, если только с внешней компонентой

(35) Ты недооцениваешь способности разработчиков типовых в части извращения и выворачивания идей разработчиков платформы