Проверил на windows 11. Воспроизвести проблему не могу. Работает. Попросил коллегу проверить на windows 10, но это займёт какое-то время. Если у вас есть возможность, присоединяйтесь к обсуждению на github, что бы дать немного больше дополнительной информации.
Конечно рассматривали, я даже в статье упомянул об этом - "не electron'ом единым"... На данный момент стабильной и удовлетворяющей нашим требованиям альтернативы electron'у я не вижу... могу ошибаться, конечно. Дело же не только в том, чтобы браузер обернуть во что-то, дело же ещё в OS API... ну банально - системные диалоги, пуши и прочее. В 2021 мы, например, играли с https://tauri.app/... написан на rust, шустрый до безобразия, но базируется на webview, что не приемлемо с точки зрения производительности клиента (надо проверить, может что изменилось за 2 года). Так что пока мы остались на electron, но, как я уже отметил, ядро очень легко связать с любым клиентом и никакой прямо вот привязанности к electron команда не испытывает... просто сейчас он в наибольшей степени соответствует нашим требованиям.
Спасибо, очень надеюсь chipmunk будет полезным иструментом для вас. Кстати мы добавили поддержку attachments для DLT. Так что если trace включает в себя какие-то файлы, они будут отображены на табе Attachments. Текстовые файлы и графические можно просмотреть прямо в chipmunk.
Мне кажется мы просто говорим с вами о разных вещах. Если не ошибаюсь, вы подразумеваете что-то вроде авторизации (или верификации?), поправьте если я не прав.
Назначение SelfKey и AssignedKey немного в другом, в ассоциировании (наверное будет более точно). Например, SelfKey { uuid: string, lang: string, age: number } (поле uuid добавляется всегда автоматически, даже если этого не сделал разработчик, uuid присваивается сервером после успешного подключения). И, например, AssignedKey { age_confirmed: bool }.
Клиент может выставить и язык, и возраст, как его душе будет угодно, но лишь сервер (после какой-то проверки) может заключить, что возраст 18+ подтверждён.
Я думаю, что понятнее будет, если мы посмотрим на гипотетический запрос, после ответа на который, нам надо сделать broadcast всем русско-говорящим клиентам 18+. Например, пришло сообщение в чат и мы хотим сделать рассылку другим клиентам, но только тем у кого подтвержден возраст и указан целевой язык.
import { Response } from "../implementation/responses/message.request";
import {
Identification,
Protocol,
} from "../implementation/responses";
import { Scope } from "../implementation/scope";
// Обработчик входящего сообщения
export function response(
request: Protocol.Message.Request,
scope: Scope
): Promise<Response> {
// Добавляем сообщение в БД или куда-то еще
...
return Promise.resolve(
new Response(
// Готовим ответ клиенту (отправителю сообщения)
new Protocol.Message.Accepted({
uuid: scope.consumer.uuid(),
})
)
// Создаем список клиентов для broadcast
.broadcast(scope.filter.filter((ident: Identification) => {
// Broadcast message будет отправлять только клиентам, удовлетворящим следующему
// условию
return ident.getAssigned()?.age_confirmed && ident.getKey().lang === 'ru';
}))
// Создаем сообщение которое будет отправлено (broadcast message)
.EventsMessage(
new Protocol.Events.Message({
...,
})
)
);
}
Если вы сейчас подумали о том, что подобные данные хранятся обычно в БД и вытаскиваются по мере необходимости - вы совершенно правы. Идея в том, чтобы часть подобных данных иметь "под рукой" для составления списков broadcast.
Стоит также упомянуть, что и по умолчанию наличие AssignedKey не требуется, равно как можно избежать и использование SelfKey (он будет создан автоматически с единственным полем - uuid). Просто в ввиду слишком большого размера статьи, мне пришлось многое опускать. В документации (вы её уже отругали :)) есть разделы, посвященные настройке producer и стратегий в отношении ключей.
Разница во владельцах. Владельцем SelfKey является клиент и только он может определять значение ключа; в свою очередь владельцем AssignedKey является сервер. То есть клиент может представить себя как ему угодно, а сервер может идентифицировать клиента по-своему, скажем добавить поле verified или что-то в этом духе.
На счёт документации вы совершено правы. Базовые моменты я описал здесь в различных секциях. Но описание конкретных методов всё ещё является слабым место. Я думаю, что это будет embedded документация, то есть встроенная непосредственно в код. Раз уж код генерируется и будут безусловно обновления, то и документацию следуют генерировать тоже.
Всегда стараюсь отвечать максимально деликатно на подобные вашему комментарии. Или просто игнорирую их. Но, знаете, сегодня не буду… надоело, пусть и полетят в меня минусы роем. Для себя я называю такие вот комментарии - «булькающая бабушка».
Суть проста - ты сделаешь что-то, поэкперементируешь, поиграешь с идеями и опишешь это и вот на горизонте появляется она, «булькающая бабушка»… всегда с единственно верным суждением и решимостью его предъявить миру - «это всё г$_&о, не нужно делать х*!?ю»
Она не интересна. Когда становится интересно пора переходить на протобаф, а не думать как сделать джейсон быстрее.
Я учту о чём мне не думать, но все равно поясню: JSON в данной статье упоминается в качестве наиболее распространённого варианта формата данных, что характерно особенно для небольших web проектов. Никто не оспаривает существование прекрасных парсеров для него (взять хотя бы тот же serde на rust). А clibri так и вовсе не использует JSON вообще и раз так, то и не оптимизирует его. Статья вообще не про это.
На счёт таймаутов вы правы, они отлавливаются на всех болевых точках в rust имплементации и будут добавлены также в typescript совсем скоро. Собственно поэтому и есть плашка alpha, что бы подсветить - не все детали ещё учтены, есть базовое решение, но работа ещё ведётся.
Конечно, protobuf - это первое что приходит на ум, и я ждал подобного вопроса. Но не упоминал о protobuf в статье лишь потому, что clibri не является ни конкурентом (куда уж мне в одиночку), ни тем более альтернативой; не в чистом виде, не в связке с gRPC. Это немного о другом.
Я по большей части работаю с web проектами, поэтому и на протокол смотрю именно с этой стороны. Часто нужно сделать какой-то несложный front-end для какого-нибудь сервиса. И каждый раз «под капотом» практически одно и тоже: транспорт, валидатор, реализация клиента, реализация сервера. Наблюдая порой за коллегами я не раз замечал, как реализация какой-нибудь связки «клиент-сервер» кочует от проекта к проекту, с каждой новой итерацией copy/paster, обрастая незначительными изменениями, то есть коллеги просто брали подходящее решение, копировали и заменяли содержание обработчиков, практически не трогая все остальное (ну разве что состав данных менялся безусловно). Но идея clibri именно в этом — дать возможность разработчику вообще не думать о том, что там делает метод send_something_somewhere. И я подумал, возможно будет интересно, если:
не описывать в протоколе ничего кроме данных (может он в рамках того же проекта будет использоваться для чего-то иного, импорта/экспорта, например)
описывая логику коммуникации (workflow) не описывать никаких функций, а описывать только возвраты и последствия возвратов. Добиться от схемы workflow однозначного и единственного толкования.
сделать так, чтобы разработчик в большей части случаев мог бы просто добавить свой код в уже готовый обработчик. То есть сгенерированное решение должно компилироваться сразу же, ещё до того, как добавлено «мясо» в обработчики.
Я не сравнивал clibri по производительность с protobuf ни с точки зрения кодирования/декодирования, ни с точки зрения экономичности, хотя, наверное, это следует сделать, но быть может немного позднее, ибо сейчас это будет сравнение автомобиля с шаттлом челленджер.
Надеюсь ответил. Ещё раз спасибо за хороший вопрос.
Спасибо за ваш комментарий.
Текущая картина такая:
TS: ~74%
Rust: ~16%
HTML, LESS, CSS, Ruby — rest
На rust сейчас наиболее ресурсоёмкие операции: индексация, декодирование/кодирование и другие. Но сессии и поиск модерируются на nodejs. Миграция ядра на rust подразумевает модерацию сессий, включая поиск, на уровне rust; на nodejs останутся лишь какие-то общие задачи. И даже в версии 3.0, я уверен доля rust не вырастет выше 30-35% и это вполне ок, ибо на front-end довольно много кода.
Уточнить: rust не «сбоку», на нем уже сейчас лежит основополагающий функционал по подготовке контента к отображению (как было сказано выше: индексация, кодирование/декодирование). Ну а с версией 3 так и все ядро будет на нем.
Спасибо за Ваш вопрос. Из структурированных форматов, сейчас есть поддержка только для DLT формата. Иные форматы воспринимаются как plain text. Между тем, Вы можете создать feature requestздесь и описать своё видение, что очень важно. Например мне сложно представить, что именно Вы хотели бы видеть в качестве поддержки логов в формате JSON. Как должна отображаться строка логов? Как текст или, например, поименованными столбцами (а если JSON имеет вложенную структуру?). Или может вы хотели бы видеть на sidebar представление выделенной строки логов как JSON pretty print? Как видите вопросов возникает масса, поэтому мы призываем создавать feature request, где Вы и мы могли бы обсудить как именно должна быть реализован тот или иной функционал.
Ниже на скрине показано как выглядит DLT файл в chipmunk. Представление строк — столбцами; плюс на sidebar разбивка по полям.
Спасибо за Ваш отклик. Поддержка tail и возможность включения любых дополнительных кодировок появится в версии 3.x вместе с упомянутой мной оптимизацией производительности. Произойдёт это не раньше чем через 1-1.5 месяца.
К сожалению, такого рода временные метки не могут быть идентифицированы прямым путём. Я имею ввиду, что это не соответствует формату YYYY, MM, DD, hh, mm, ss etc. Как отличить «20200825223600050161» от простого числа логах? Полагаю, что никак.
Кроме того, в вашем случае нужно не только найти значение, но и преобразовать его, что несколько осложняет задачу.
Для решения подобных задач в следующих версиях мы хотим добавить определение формата, как регулярного выражения с поименованными группами. Что-то вроде.
Какого рода интеграцию вы имеете ввиду? Например, интеграция с DLT понятна — декодирование и разбиение на столбцы для удобства чтнения. С opentracing немного не ясно, что именно нужно интегрировать. Поясните пожалуйста.
Спасибо за разъяснения.
На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.
Спасибо за ваш комментарий.
Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?
Thanks!
Проверил на windows 11. Воспроизвести проблему не могу. Работает. Попросил коллегу проверить на windows 10, но это займёт какое-то время.
Если у вас есть возможность, присоединяйтесь к обсуждению на github, что бы дать немного больше дополнительной информации.
Спасибо за рапорт. Создал issue с высоким приоритетом. Проверим обязательно в самое ближайшее время.
Конечно рассматривали, я даже в статье упомянул об этом - "не electron'ом единым"... На данный момент стабильной и удовлетворяющей нашим требованиям альтернативы electron'у я не вижу... могу ошибаться, конечно.
Дело же не только в том, чтобы браузер обернуть во что-то, дело же ещё в OS API... ну банально - системные диалоги, пуши и прочее. В 2021 мы, например, играли с https://tauri.app/... написан на rust, шустрый до безобразия, но базируется на webview, что не приемлемо с точки зрения производительности клиента (надо проверить, может что изменилось за 2 года). Так что пока мы остались на electron, но, как я уже отметил, ядро очень легко связать с любым клиентом и никакой прямо вот привязанности к electron команда не испытывает... просто сейчас он в наибольшей степени соответствует нашим требованиям.
спасибо!
Спасибо, очень надеюсь chipmunk будет полезным иструментом для вас. Кстати мы добавили поддержку attachments для DLT. Так что если trace включает в себя какие-то файлы, они будут отображены на табе Attachments. Текстовые файлы и графические можно просмотреть прямо в chipmunk.
Спасибо за хорошее замечание. В переименовании действительно есть смысл.
Нет клиент не может изменить
uuid(хоть это и поле ключа),uuidназначается только сервером.Мне кажется мы просто говорим с вами о разных вещах. Если не ошибаюсь, вы подразумеваете что-то вроде авторизации (или верификации?), поправьте если я не прав.
Назначение
SelfKeyиAssignedKeyнемного в другом, в ассоциировании (наверное будет более точно). Например,SelfKey { uuid: string, lang: string, age: number }(поле uuid добавляется всегда автоматически, даже если этого не сделал разработчик, uuid присваивается сервером после успешного подключения). И, например,AssignedKey { age_confirmed: bool }.Клиент может выставить и язык, и возраст, как его душе будет угодно, но лишь сервер (после какой-то проверки) может заключить, что возраст 18+ подтверждён.
Я думаю, что понятнее будет, если мы посмотрим на гипотетический запрос, после ответа на который, нам надо сделать broadcast всем русско-говорящим клиентам 18+. Например, пришло сообщение в чат и мы хотим сделать рассылку другим клиентам, но только тем у кого подтвержден возраст и указан целевой язык.
Если вы сейчас подумали о том, что подобные данные хранятся обычно в БД и вытаскиваются по мере необходимости - вы совершенно правы. Идея в том, чтобы часть подобных данных иметь "под рукой" для составления списков broadcast.
Стоит также упомянуть, что и по умолчанию наличие
AssignedKeyне требуется, равно как можно избежать и использованиеSelfKey(он будет создан автоматически с единственным полем -uuid). Просто в ввиду слишком большого размера статьи, мне пришлось многое опускать. В документации (вы её уже отругали :)) есть разделы, посвященные настройке producer и стратегий в отношении ключей.Разница во владельцах. Владельцем
SelfKeyявляется клиент и только он может определять значение ключа; в свою очередь владельцемAssignedKeyявляется сервер. То есть клиент может представить себя как ему угодно, а сервер может идентифицировать клиента по-своему, скажем добавить полеverifiedили что-то в этом духе.На счёт документации вы совершено правы. Базовые моменты я описал здесь в различных секциях. Но описание конкретных методов всё ещё является слабым место. Я думаю, что это будет embedded документация, то есть встроенная непосредственно в код. Раз уж код генерируется и будут безусловно обновления, то и документацию следуют генерировать тоже.
Спасибо за ваш комментарий.
Всегда стараюсь отвечать максимально деликатно на подобные вашему комментарии. Или просто игнорирую их. Но, знаете, сегодня не буду… надоело, пусть и полетят в меня минусы роем. Для себя я называю такие вот комментарии - «булькающая бабушка».
Суть проста - ты сделаешь что-то, поэкперементируешь, поиграешь с идеями и опишешь это и вот на горизонте появляется она, «булькающая бабушка»… всегда с единственно верным суждением и решимостью его предъявить миру - «это всё г$_&о, не нужно делать х*!?ю»
Я учту о чём мне не думать, но все равно поясню: JSON в данной статье упоминается в качестве наиболее распространённого варианта формата данных, что характерно особенно для небольших web проектов. Никто не оспаривает существование прекрасных парсеров для него (взять хотя бы тот же serde на rust). А clibri так и вовсе не использует JSON вообще и раз так, то и не оптимизирует его. Статья вообще не про это.
На счёт таймаутов вы правы, они отлавливаются на всех болевых точках в rust имплементации и будут добавлены также в typescript совсем скоро. Собственно поэтому и есть плашка alpha, что бы подсветить - не все детали ещё учтены, есть базовое решение, но работа ещё ведётся.
Спасибо. Добра вам и терпимости к инакомыслию.
Большое спасибо за хороший вопрос.
Конечно, protobuf - это первое что приходит на ум, и я ждал подобного вопроса. Но не упоминал о protobuf в статье лишь потому, что clibri не является ни конкурентом (куда уж мне в одиночку), ни тем более альтернативой; не в чистом виде, не в связке с gRPC. Это немного о другом.
Я по большей части работаю с web проектами, поэтому и на протокол смотрю именно с этой стороны. Часто нужно сделать какой-то несложный front-end для какого-нибудь сервиса. И каждый раз «под капотом» практически одно и тоже: транспорт, валидатор, реализация клиента, реализация сервера. Наблюдая порой за коллегами я не раз замечал, как реализация какой-нибудь связки «клиент-сервер» кочует от проекта к проекту, с каждой новой итерацией copy/paster, обрастая незначительными изменениями, то есть коллеги просто брали подходящее решение, копировали и заменяли содержание обработчиков, практически не трогая все остальное (ну разве что состав данных менялся безусловно). Но идея clibri именно в этом — дать возможность разработчику вообще не думать о том, что там делает метод send_something_somewhere. И я подумал, возможно будет интересно, если:
не описывать в протоколе ничего кроме данных (может он в рамках того же проекта будет использоваться для чего-то иного, импорта/экспорта, например)
описывая логику коммуникации (workflow) не описывать никаких функций, а описывать только возвраты и последствия возвратов. Добиться от схемы workflow однозначного и единственного толкования.
сделать так, чтобы разработчик в большей части случаев мог бы просто добавить свой код в уже готовый обработчик. То есть сгенерированное решение должно компилироваться сразу же, ещё до того, как добавлено «мясо» в обработчики.
Я не сравнивал clibri по производительность с protobuf ни с точки зрения кодирования/декодирования, ни с точки зрения экономичности, хотя, наверное, это следует сделать, но быть может немного позднее, ибо сейчас это будет сравнение автомобиля с шаттлом челленджер.
Надеюсь ответил. Ещё раз спасибо за хороший вопрос.
Текущая картина такая:
На rust сейчас наиболее ресурсоёмкие операции: индексация, декодирование/кодирование и другие. Но сессии и поиск модерируются на nodejs. Миграция ядра на rust подразумевает модерацию сессий, включая поиск, на уровне rust; на nodejs останутся лишь какие-то общие задачи. И даже в версии 3.0, я уверен доля rust не вырастет выше 30-35% и это вполне ок, ибо на front-end довольно много кода.
Уточнить: rust не «сбоку», на нем уже сейчас лежит основополагающий функционал по подготовке контента к отображению (как было сказано выше: индексация, кодирование/декодирование). Ну а с версией 3 так и все ядро будет на нем.
Ниже на скрине показано как выглядит DLT файл в chipmunk. Представление строк — столбцами; плюс на sidebar разбивка по полям.
Что касается горячих клавиш, создал issue.
Кроме того, в вашем случае нужно не только найти значение, но и преобразовать его, что несколько осложняет задачу.
Для решения подобных задач в следующих версиях мы хотим добавить определение формата, как регулярного выражения с поименованными группами. Что-то вроде.
(?<YYYY>\d{4})\s(?<MM>\d{2})(?<DD>\d{2})\s(?<hh>\d{2})(?<mm>\d{2})(?<ss>\d{2})Это должно будет работать и для вашего случая
На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.
Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?