1. 4 байт на один символ это слишком большой оверхид для наших приложений. У нас очень много строк живут в памяти и они могут занимать существенный процент от общего потребления
2. Visual C++ это до сих пор наилучший выбор при компиляции под Windows. GCC не обеспечивает инфраструктуру для продуктивной и комфортной работы под Windows.
Да, приводит — новые версии компиляторов могут перестать (и перестают) компилировать код, написанный по старым стандартам :(
Использовать новые возможности, имея часть кода в старом стандарте, часто очень затруднительно, а иногда просто невозможно.
В статье мы старались описать — почему и зачем переводили.
Возможно, не вполне удачно?
Переход на новый стандарт, как мы предполагали, позволил бы нам писать многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода.
И мы не ошиблись.
См. также раздел «Итоги» статьи, в частности
После миграции у разработчиков появилось больше возможностей. Если раньше у нас была своя доработанная версия STL и один неймспейс std, то теперь у нас в неймспейсе std находятся стандартные классы из встроенных библиотек компилятора, в неймспейсе stdx – наши, оптимизированные для наших задач строки и контейнеры, в boost – свежая версия boost. И разработчик использует те классы, которые оптимально подходят для решения его задач.
Основная идея теперь понятна — сервер взаимодействия разрабатывается, как некая готовая архитектура коммуникации для различных платформ, что, конечно, предполагает открытый API. В виду его закрытости и достаточно плотной интеграции с некоторыми объектами платформы 1С, я грешным делом, подумал, что эта история будет работать только из 1С-ных решений (конкретная ЦА, если угодно). Значит, ждём открытого API?)
По срокам сказать не смогу, но такая цель перед нами ставилась с самого начала, так что это должно случиться.
Немного поясню о моменте с «прочтеностью». Если создать сообщение на вкладке «обсуждения» и отослать его пользователю, то получатель, находящийся в онлайн, получит уведомление (внизу экрана), но, если он не прочтёт сообщение (визуально текст сообщения НЕ будет отображен ему на вкладке «обсуждения») и закроет сеанс 1С, то, при следующем старте сеанса — он снова получит это уведомление (внизу экрана). То есть, технически, это сообщение не удаляется из таблицы «unreaded» пока пользователь его не увидит глазами.
Если я правильно понял сценарий, то мы на сервере это не делаем (обсуждение не пропадет из таблицы unread, пока пользователь/код не вызовут setLastReadMessageId). Возможно, это уже при вызове из языка делается. Надо у команды тонкого клиента спросить.
Если же я программно (кодом в 1С) создам техническое/неконтекстное сообщение на источнике (например, уведомление о критическом изменении курса валютной пары, которое пользователь-приемник должен увидеть в отдельной форме с графиками и прочей аналитикой, эту форму пользователь должен открыть нажатием кнопки на начальной странице (логично, что это кнопка должна «покраснеть»)), то на приемнике:
Я программно (кодом) подписываюсь на событие нового сообщения нужного обсуждения/канала(«conversation»), получаю новое сообщение, когда нахожусь в онлайн, и делаю такие вещи, как: программное открытие уведомления внизу экрана, окрашивание кнопки открытия формы, проигрывание сигнала тревоги и т.п. прекрасные штуки. Но, если пользователь-приемник не проявил никакой реакциии и закрыл сеанс 1С, то, при следующем открытии сеанса 1С — приемник НЕ получуит это сообщение снова (в отличие от сценария доставки видимого сообщения на вкладке «Обсуждения»). Это произойдет потому, что строка доставки сообщения для пользователя удаляется из таблицы «unreaded» сразу в тот момент, когда отрабатывает подписка на получение новых сообщений.
Таким образом, возникает 2 различных поведения сервера взаимодействия по удалению признака необходимости оповещения приемника в зависимости от контекста процессинга сообщения. Иными словами появляется такой «условный» признак, как «прочтённость». И мне, например, бы очень хотелось этим признаком управлять в зависимости от того — завершён ли бизнес-процесс коммуникации (в моём примере — нажатие на красную кнопку) или нет.
И ещё один вопрос возник: проводились ли какие-либо синтетические тесты нагрузки СВ, т.е. где отправителем и приемником является некий «шустрый» многопоточный сервис (не 1С, видимо), чтобы протестировать скорость процессинга сообщений (например, количество полученных/доставленных сообщений в секунду в зависимости от количества источников/получателей). Ну, например, для http обычно проводят такие базовые тесты утилитой ab.
В таком виде не проводились, но идея хорошая, спасибо! Мы делаем нагрузочное тестирование, но с упором на интерактивные сценарии. Также стараемся мониторить отзывчивость системы в production и оперативно что-то доделывать, когда видим появление узких мест. Но самому интересно провести такой тест.
Если речь идет о внешних ActiveX-компонентах, которые использовались в ПолеHTMLДокумента в нативном клиенте, то их функционирование в 8.3.14 прекратится, WebKit эту технологию не поддерживает.
Главная причина отказа от Chromium в пользу WebKit была в том, что у WebKit для исполнения JavaScript используется библиотека JavaScriptCore, на основе которой у нас уже была реализована работа с DOM для Linux. Эту реализацию мы использовали в готовом виде для Windows и macOS, т.к. API у этой библиотеки для всех ОС одинаковый.
В случае с Blink, хотя за основу и была взята библиотека WebCore, далее движок развивался независимо. Поэтому WebKit выглядит предпочтительнее в смысле унификации поведения нашего клиента в разных ОС.
Насколько помню, в мобильной платформе событие ПриНажатии происходит только если нажатие приводит к переходу на другую страницу. У вас нажатие приводит к переходу на другую страницу?
Совершенно верно. Я даже его на картинке нарисовал :)
Но Gecko у нас отвалился на ранней стадии рассмотрения, причину уже и не вспомню.
А у вас есть пример удачного использования Gecko? Кроме Firefox.
Будет здорово, если поделитесь.
Пока нет.
К выпуску версии 8.3.14 (ориентировочно — конец 2018 г.) планируем выложить исходники WebKit с нашими доработками здесь: github.com/1C-Company-third-party
В личке aavolkov задал ряд инетресных вопросов, переношу сюда вместе с ответами.
ВОПРОС: Первый вопрос (архитектурный): почему не очередь сообщений типа RabbitMQ? Там же адресная доставка, масштабируемость, нагрузки и прочее реализованы из коробки. Нужно всего-лишь прикрутить «воркер» к платформе и всё будет работать, да и на «плюсах» эти воркеры, конечно, есть. К тому-же RabbitMQ запилен на Erlang-е, который очень бережно относится к потокам (тредам) и прочему (типа распределения нагрузки, мониторинга состояния процессов), чего нельзя сказать о том-же самом в Java (без методичной настройки снаружи и педантичного многопоточного ковыряния внутри).
RabbitMQ прекрасен, и мы много его используем в других проектах. Если бы мы делали отдельно чат и отдельно механизм publish-subscribe, второй совершенно точно делали бы через rabbitMQ (и AMQP в платформе). Но нужен был чат и транспорт два в одном. Для чата в качестве клиента помимо 1С: Предприятия ожидался сайт и standalone-приложение, так что вебсокет показался удобнее. А вебсокет в rabbitmq на тот момент (2014-2015 год) то ли не вызвал большого доверия, то ли не существовал. Возможен еще один вариант — не влез в osgi. Иногда даже у библиотек с заявленной поддержкой osgi по факту она реализована плохо и требует допиливания. Может быть, мы вообще забыли включить его в сравнение, потому что он был не очень на слуху. Не хочу вас обманывать, про тогда не скажу, сейчас обязательно рассмотрели бы такой вариант. Может, еще и рассмотрим в будущем.
ВОПРОС: Если есть ElasticSearch, то почему нет возможности выбрать сообщения поиском из встроенного языка платформы (8.3.12 и 3.0.6)?
Мы индексируем сообщения в ES, но пока не успели поддержать поиск сообщений/наименований_форм на уровне встроенного языка.
ВОПРОС: Почему при создании обсуждения с единственным участником «все пользователи» и отсылки в это обсуждение сообщения — в БД СВ (postresql) сообщения регистрируются к доставке «всем» и «каждому пользователю» в отдельности (я сужу по таблице «unread_conversation»)? Я конечно, понимаю, что нужно удалять прочитанные «уведомления» для каждого конкретного пользователя, но может инфу о том, что конкретный пользователь прочёл сообщение хранить в самой БД 1С с возможностью управления этим параметром (типа, пометить сообщения с такой-то даты непрочтёнными или прочтёнными, как в почте)?
Думаю, тут опять же вопрос других клиентов — в 1С вы, конечно, можете хранить, но что делать остальным клиентам? Про unread_conversation вы совершенно верно заметили, это для того, чтобы снимать непрочитанность для каждого пользователя в отдельности. Также у нас есть место, где хранится ID и дата последнего прочитанного сообщения — таблица conversation_user (last_read_message_at, last_read_message_id). Но да, это снова на сервере.
ВОПРОС: (он вытек из третьего, когда я копал): Как удалить пользователя из СВ, который был физически удалён из базы данных 1С (напомню, 8.3.12 и 3.0.6), т.е. пользователь, при удалении из БД 1С, автоматом не удаляется из БД СВ и нет какой-то функции, которую бы можно было вызвать из языка платформы.
Сейчас никак, но мы сами редко на уровне ИБ и удаляем пользователей по-настоящему. Обычно прибавляем к нему «ув.» и оставляем в таком виде. Так повелось задолго до системы взаимодействия, так что у нас проблема так остро не стоит. Но, наверное, дать такую возможность было бы неплохо, согласен с вами.
ВОПРОС: я не могу понять — если сообщение обсуждения создавать во вкладке «Обсуждения», то адресат, пока не прочитает эти сообщения, будет каждый раз получать их при входе в «1С» (в виде уведомлений внизу экрана).
Если же неконтекстное сообщение создать (послать) и прочитать программно (обсуждение с признаком «Отображение = ложь», чтобы их визуально не отображать, конечно), то факт получения сообщения обработчиком новых сообщений уже считает сообщение прочтённым, хотя по бизнесу — оно может требовать реакции пользователя и, пока пользователь не отреагировал (даже между сеансами) — сообщение должно быть непрочтённым. То есть, правильно ли я понял, что управления прочтённостьюсообщений в языке платформы нет?
Я не совсем понял этот сценарий, вы написали
сообщение создать (послать) и прочитать программно
Так вы его прочитали или нет?
Смотрите, модель такая: оповещения приходят тем, кто онлайн.
Если пользователь оффлайн, то при старте он запросит обновления по таблице unread_conversation (это не оповещения — попадают ли они тут в обработчик я не подскажу). Для чтения есть параметр visible, если клиент передает его равным true, то из unread_conversation приедут только видимые обсуждения. Что из этого выведено в язык тоже, к сожалению, подсказать не могу (но могут на v8).
aavolkov — спасибо за хорошие сложные вдумчивые вопросы!
2. Visual C++ это до сих пор наилучший выбор при компиляции под Windows. GCC не обеспечивает инфраструктуру для продуктивной и комфортной работы под Windows.
Использовать новые возможности, имея часть кода в старом стандарте, часто очень затруднительно, а иногда просто невозможно.
Возможно, не вполне удачно?
И мы не ошиблись.
См. также раздел «Итоги» статьи, в частности
По срокам сказать не смогу, но такая цель перед нами ставилась с самого начала, так что это должно случиться.
Если я правильно понял сценарий, то мы на сервере это не делаем (обсуждение не пропадет из таблицы unread, пока пользователь/код не вызовут setLastReadMessageId). Возможно, это уже при вызове из языка делается. Надо у команды тонкого клиента спросить.
В таком виде не проводились, но идея хорошая, спасибо! Мы делаем нагрузочное тестирование, но с упором на интерактивные сценарии. Также стараемся мониторить отзывчивость системы в production и оперативно что-то доделывать, когда видим появление узких мест. Но самому интересно провести такой тест.
В случае с Blink, хотя за основу и была взята библиотека WebCore, далее движок развивался независимо. Поэтому WebKit выглядит предпочтительнее в смысле унификации поведения нашего клиента в разных ОС.
Но Gecko у нас отвалился на ранней стадии рассмотрения, причину уже и не вспомню.
А у вас есть пример удачного использования Gecko? Кроме Firefox.
Будет здорово, если поделитесь.
К выпуску версии 8.3.14 (ориентировочно — конец 2018 г.) планируем выложить исходники WebKit с нашими доработками здесь: github.com/1C-Company-third-party
Если не получится воспроизвести — запрошу у вас видео.
Согласен, влить было бы хорошо, но пока руки не доходят.
Спасибо за вопрос по делу, сейчас добавлю в статью.
RabbitMQ прекрасен, и мы много его используем в других проектах. Если бы мы делали отдельно чат и отдельно механизм publish-subscribe, второй совершенно точно делали бы через rabbitMQ (и AMQP в платформе). Но нужен был чат и транспорт два в одном. Для чата в качестве клиента помимо 1С: Предприятия ожидался сайт и standalone-приложение, так что вебсокет показался удобнее. А вебсокет в rabbitmq на тот момент (2014-2015 год) то ли не вызвал большого доверия, то ли не существовал. Возможен еще один вариант — не влез в osgi. Иногда даже у библиотек с заявленной поддержкой osgi по факту она реализована плохо и требует допиливания. Может быть, мы вообще забыли включить его в сравнение, потому что он был не очень на слуху. Не хочу вас обманывать, про тогда не скажу, сейчас обязательно рассмотрели бы такой вариант. Может, еще и рассмотрим в будущем.
Мы индексируем сообщения в ES, но пока не успели поддержать поиск сообщений/наименований_форм на уровне встроенного языка.
Думаю, тут опять же вопрос других клиентов — в 1С вы, конечно, можете хранить, но что делать остальным клиентам? Про unread_conversation вы совершенно верно заметили, это для того, чтобы снимать непрочитанность для каждого пользователя в отдельности. Также у нас есть место, где хранится ID и дата последнего прочитанного сообщения — таблица conversation_user (last_read_message_at, last_read_message_id). Но да, это снова на сервере.
Сейчас никак, но мы сами редко на уровне ИБ и удаляем пользователей по-настоящему. Обычно прибавляем к нему «ув.» и оставляем в таком виде. Так повелось задолго до системы взаимодействия, так что у нас проблема так остро не стоит. Но, наверное, дать такую возможность было бы неплохо, согласен с вами.
Я не совсем понял этот сценарий, вы написали
Так вы его прочитали или нет?
Смотрите, модель такая: оповещения приходят тем, кто онлайн.
Если пользователь оффлайн, то при старте он запросит обновления по таблице unread_conversation (это не оповещения — попадают ли они тут в обработчик я не подскажу). Для чтения есть параметр visible, если клиент передает его равным true, то из unread_conversation приедут только видимые обсуждения. Что из этого выведено в язык тоже, к сожалению, подсказать не могу (но могут на v8).
aavolkov — спасибо за хорошие сложные вдумчивые вопросы!
Да, действительно, про журнал забыл.