Я планирую, как лучше всего добавить поддержку ActivityPub для тегов, то есть разрешить тегам выступать в качестве акторов ActivityPub. Модели с поддержкой ActivityPub требуется индивидуальное хранилище данных для каждой записи. Один из способов реализовать это — использование пользовательских полей, например:
Существуют и другие способы достижения того же результата, но пользовательские поля, пожалуй, являются наиболее простым решением и обеспечат наибольшую согласованность с моделью данных как плагина ActivityPub, так, возможно, и самого Discourse.
Поэтому я хотел бы сначала оценить готовность сообщества к добавлению поддержки CustomField для тегов, для чего я могу создать PR в репозиторий discourse/discourse.
Я сделал PR по этому вопросу. Обратите внимание, что это максимально простая возможная реализация, так как ни сериализация списка тегов, ни редактирование информации (т. е. в интерфейсе информации о теге) не требуются:
@sam Мне интересно, что ты думаешь по этому поводу? Мы уже давно активно отговариваем от использования пользовательских полей внутри компании, поэтому мне не очень хочется открывать эту возможность для тегов.
Думаю, привлекательность пользовательских полей заключается в том, что у них есть заранее определённая структура интеграции, например, реестр плагинов и API плагинов. С моей точки зрения, наличие стабильного способа интеграции с основной моделью предпочтительнее создания собственной интеграции.
Я понимаю, что вы имеете в виду насчёт пользовательских полей. Думаю, я бы сказал, что эти проблемы существуют в любом случае. Наличие или отсутствие пользовательских полей для тегов не изменит этого.
Со временем проблема с пользовательскими полями заключалась в том, что они оказались слишком гибкими, и люди склонны хранить в одном байте огромные сложные структуры.
Я полностью понимаю, что вы хотите получить своего рода «официальную» схему того, как это следует делать.
Думаю, стоит задать вопрос вам… о чём именно идёт речь?
Должно ли Discourse при отображении каждого тега показывать что-то особенное? (Это сложная задача для оптимизации, поскольку тегов отображается много мест)
Речь только о странице тега?
Это просто фоновая задача, настраиваемая администраторами?
Давайте начнём с этого. Что именно вы хотите сделать? Что видят различные пользователи и так далее…
Они будут хранить данные ActivityPub, связанные с тегом, выполняющим роль актора ActivityPub. Мне не нужна какая-либо сериализация для каких-либо частей клиента в discourse/discourse. Пользователь не увидит эти данные ни в одной части обычного клиента discourse/discourse. Данные будут сериализованы для административного клиента вместе с другими данными, однако этим управляет плагин через выделенные административные маршруты плагина. Как вы правильно заметили, сериализация в существующих маршрутах тегов discourse/discourse (или в сериализаторе сайта) была бы сложной по разным причинам, и я не хочу этого предпринимать, поэтому я не добавил методы предварительной загрузки или редактирования через API.
Помимо наличия стабильного API для работы, они предпочтительны в плагине ActivityPub, потому что плагин хранит активности ActivityPub в отдельном наборе моделей данных — таблицах discourse_activity_pub_*, которые затем интегрируются с discourse/discourse через определённые API плагина и пользовательские поля основных моделей. Здесь есть намеренная избыточность, чтобы обеспечить правильное разделение ответственности между данными Discourse и ActivityPub. Поскольку у Discourse и ActivityPub есть серии взаимосвязанных, но различных концепций и моделей данных, необходимо чётко разграничивать данные ActivityPub и данные discourse/discourse, чтобы сохранить ясность (и здравый смысл) в таком большом и сложном плагине. Использование пользовательских полей в качестве точки интеграции очень полезно для поддержания этого разделения чистым и стабильным.
Краткое объяснение этого приведено в файле README плагина.
Извините за задержку, @angus. Можем ли мы добавить поддержку тегов в ActivityPub без пользовательских полей для тегов?
Я понимаю, что это не соответствует модели данных, которую мы сейчас используем для категорий, но это наш предпочтительный подход. Добавление поддержки пользовательских полей для тегов в ядре откроет путь к их полной поддержке в ядре. Я знаю, что ваш PR этого не добавляет, но он подтолкнёт следующего разработчика к тому, чтобы немного приоткрыть эту дверь.
