У меня совершенно другой опыт. Тоже сперва думал, что отображение - это важно. Пробовал и Obsidian, и что-то самописное. Это, может, и было важно в эпоху до ИИ. Но когда я начал строить систему долговременной памяти на основе ИИ, оказалось, что вся эта визуальщина - совершенно не нужна. Она только создаёт иллюзию контроля и доступности знаний ценой неимоверных усилий и самодисциплины. А по факту в моей системе это оказалось рудиментом, которым я никогда не пользуюсь.
Сейчас, обращаясь к новой теме, ИИ сам поднимает из моего накопленного массива знаний то, что нужно здесь и сейчас, возвращая забытый контекст. Да, я и сам помню, что когда-то касался нужной темы, но детали уже забыты. И совершенно не представляю, как мне Obsidian или любая другая система визуализации может сейчас помочь. Теперь это просто красивая прослойка, в которую я не заглядываю. ИИ - это новый интерфейс доступа, который сокращает усилия, необходимые для поиска.
Главный вопрос - структура и обвязка, которые будут удобны для наполнения, поиска и извлечения накопленных знаний.
Действительно, реализовать свою версию достаточно легко :) Как отдельную библиотеку выпускать не стал, т.к. подумал, что без сервиса, смысла в этом особого нет. Локально и так всё понятно, а в случае с другим сервисом, скорее всего тоже захотят своё решение. Но может я не прав, и будет спрос на такую библиотеку?
По поводу очистки, всё оказалось достаточно просто. Для всех асинхронных вызовов используется одна и та же обёртка, и количество вспомогательных вызовов всегда одинаково. Просто вырезается одно и то же количество строк. Но если логика для обёрток вдруг разделится, то вы правы, можно проверять по имени скоупа, он тоже передаётся при создании, и зависит от того, что оборачиваем. По имени производим склейку финального стактрейса, что бы на UI было удобнее анализировать.
Про локальный дебаг - да, действительно, лишние обёртки могут создать сложности, но лично мне, на практике не мешали. В любом случае, можно просто отключить (не инициализировать модуль) при локальной разработке.
У меня совершенно другой опыт. Тоже сперва думал, что отображение - это важно. Пробовал и Obsidian, и что-то самописное. Это, может, и было важно в эпоху до ИИ. Но когда я начал строить систему долговременной памяти на основе ИИ, оказалось, что вся эта визуальщина - совершенно не нужна. Она только создаёт иллюзию контроля и доступности знаний ценой неимоверных усилий и самодисциплины. А по факту в моей системе это оказалось рудиментом, которым я никогда не пользуюсь.
Сейчас, обращаясь к новой теме, ИИ сам поднимает из моего накопленного массива знаний то, что нужно здесь и сейчас, возвращая забытый контекст. Да, я и сам помню, что когда-то касался нужной темы, но детали уже забыты. И совершенно не представляю, как мне Obsidian или любая другая система визуализации может сейчас помочь. Теперь это просто красивая прослойка, в которую я не заглядываю. ИИ - это новый интерфейс доступа, который сокращает усилия, необходимые для поиска.
Главный вопрос - структура и обвязка, которые будут удобны для наполнения, поиска и извлечения накопленных знаний.
Да, так было бы более практично. Просто хотелось, что бы пример для патчинга и с прокси были визуально похожи и максимально простыми.
Действительно, реализовать свою версию достаточно легко :)
Как отдельную библиотеку выпускать не стал, т.к. подумал, что без сервиса, смысла в этом особого нет. Локально и так всё понятно, а в случае с другим сервисом, скорее всего тоже захотят своё решение. Но может я не прав, и будет спрос на такую библиотеку?
По поводу очистки, всё оказалось достаточно просто. Для всех асинхронных вызовов используется одна и та же обёртка, и количество вспомогательных вызовов всегда одинаково. Просто вырезается одно и то же количество строк. Но если логика для обёрток вдруг разделится, то вы правы, можно проверять по имени скоупа, он тоже передаётся при создании, и зависит от того, что оборачиваем. По имени производим склейку финального стактрейса, что бы на UI было удобнее анализировать.
Про локальный дебаг - да, действительно, лишние обёртки могут создать сложности, но лично мне, на практике не мешали. В любом случае, можно просто отключить (не инициализировать модуль) при локальной разработке.