angus
(Angus McLeod)
1
我正在规划如何最好地为 Tags 添加 ActivityPub 支持,即允许 Tags 成为 ActivityPub Actor。支持 ActivityPub 的模型需要特定记录的自定义存储。一种实现方式是使用自定义字段,例如:
还有其他方法可以实现相同的结果,但自定义字段可能是最直接的方法,并且与 ActivityPub 插件以及可能与 Discourse 本身的数据模型最为一致。
因此,我想先了解一下将 CustomField 支持添加到 Tags 的意愿,我可以为此向 discourse/discourse 提交一个 PR。
抄送 @pmusaraj
3 个赞
angus
(Angus McLeod)
2
我已经为此提交了一个 PR。请注意,这是最基本的实现,因为标签列表序列化或信息编辑(即在标签信息 UI 中)都不是必需的:
1 个赞
tgxworld
(Alan Tan)
3
@sam 我很好奇你怎么看?我们一直在积极地阻止在内部使用自定义字段,所以我不热衷于为标签开放这个。
sam
(Sam Saffron)
4
是的,我通常不赞成,这最终会在以后造成太多的痛苦和折磨。
@angus 为什么不在这里添加一个带有 tag_id 列的新表呢?
1 个赞
angus
(Angus McLeod)
5
是的,我可以。\n\n我猜自定义字段的吸引力在于它们具有预定义的集成结构,例如插件注册表和插件 API。从我的角度来看,拥有一个稳定的与核心模型集成的方式比从头开始构建自定义集成要好。\n\n我知道你的意思,关于自定义字段。我想我会说那些问题无论如何都存在。标签自定义字段是否存在都不会改变这一点。\n\n但还有其他选择,所以由你决定 
3 个赞
sam
(Sam Saffron)
6
随着时间的推移,自定义字段的问题在于它们过于灵活,人们倾向于将庞大复杂的结构存储在数据库的 blob 中。
我完全理解您想要某种“官方”的实现方式。
我猜想把问题抛回给你……我们具体在谈论什么?
- 每次 discourse 显示标签时,它都需要显示一些特殊的东西吗?(这是一个优化方面的怪物,因为标签显示的地方有很多)
- 这仅仅是标签页面吗?
- 这仅仅是管理员配置的后台任务吗?
我猜我们先从那里开始?您具体想做什么?各种用户会看到什么?等等……
2 个赞
angus
(Angus McLeod)
7
他们将存储与充当 ActivityPub actor 的标签相关联的 ActivityPub 数据。我不需要将任何部分序列化到 discourse/discourse 的客户端中。用户不会在 discourse/discourse 的任何常规客户端部分看到这些数据。数据将与其它数据一起序列化到管理员客户端,但这由插件在专用的插件管理员路由中管理。正如您所说,在现有的 discourse/discourse 标签路由(或站点序列化器)中进行序列化会很棘手,原因有很多,而且我也不想尝试,这就是为什么我没有添加预加载或可编辑的 API 方法。
除了拥有稳定的 API 可供使用之外,它们在 ActivityPub 插件中更受青睐的原因是,该插件将 ActivityPub 活动存储在一组单独的数据模型中,即 discourse_activity_pub_* 表,然后通过定义的插件 API 和核心模型的自定义字段与 discourse/discourse 集成。这里存在一些故意的冗余,以确保 Discourse 和 ActivityPub 数据之间有适当的关注点分离。由于 Discourse 和 ActivityPub 具有一系列相互关联但不同的概念和数据模型,因此在处理一个大型且复杂的插件时,保持 ActivityPub 数据和 discourse/discourse 数据之间的清晰区别是必要的,以保持一定的清晰度(和理智)。使用自定义字段作为集成点在保持这种分离的清洁和稳定方面非常有用。
插件的自述文件中对此有简要说明。
2 个赞
pmusaraj
(Penar Musaraj)
9
非常抱歉耽搁了,@angus。我们能否尝试在不使用标签自定义字段的情况下为 ActivityPub 添加标签支持?
我知道这与我们目前在类别方面使用的数据模型不一致,但这是我们的首选方法。在核心中添加标签的自定义字段支持意味着我们将为核心中的完整标签支持打开大门,我知道您的 PR 没有添加这个,但它会促使下一位开发者稍微推开这扇门。
1 个赞