From b060ea05a945a60a5a6c8b3a503d204b5f6e7996 Mon Sep 17 00:00:00 2001 From: satori Date: Sun, 13 Feb 2022 14:15:11 +0800 Subject: [PATCH] pb --- fmhub.js | 14 ++++++++++++- index.js | 64 +++++++++++++++++++++++++++++++------------------------- 2 files changed, 48 insertions(+), 30 deletions(-) diff --git a/fmhub.js b/fmhub.js index 51a6b13..0733e7c 100644 --- a/fmhub.js +++ b/fmhub.js @@ -25,7 +25,19 @@ export default class fmhub { constructor() { this.用户订阅 = new interrelated() this.用户会话 = new interrelated() - this.终端注视 = new interrelated() + this.终端注视 = new interrelated() // onlookers + } + + 围观作品(对象路径, 围观者会话) { + // 存储模式为 { key: ws, value: url} + } + + 变更作品(对象路径) { + // 直接通过 对象路径 查询所有在围观的会话, 然后推送通知 + // 当终端改变了围观某个作品时, 通知修改围观对象 + // 当终端结束了观看某个作品时. 要移除围观, + // 当终端断开连接时, 要移除围观 + // 于是这也要一套关系绑定... } 订阅频道(fid, uid) { diff --git a/index.js b/index.js index d072b67..98503bf 100644 --- a/index.js +++ b/index.js @@ -299,12 +299,19 @@ function object_patch(req, res, next) { // 如何加入订阅和取消订阅? 如何判断自己是否已经订阅? // 关注了此对象的用户们(如果存在) - if (Array.isArray(doc.fm)) { - doc.fm.forEach(uid => { - FM.发送消息("PATCH", req.session.account.uid, data) - // 应当是向每个用户发送消息, 而不是向整个频道发送消息 - }) - } + //if (Array.isArray(doc.fm)) { + // doc.fm.forEach(uid => { + // FM.发送消息("PATCH", req.session.account.uid, data) + // // 应当是向每个用户发送消息, 而不是向整个频道发送消息 + // // 或是认为此对象即是一个频道 + // // 此外, 如何判定游客当前客户端的视野? + // // 文章更新但角色未必在线, 而消息通知是要具体到账户, 因而是向消息盒子发生而不是向fm发送 + // // 因此, 此处并不存在频道订阅问题 + // // 而针对正在被观看的, 可以构建频道, 此为有限量, 故而可以临时建立无需落盘的通道(可以是随机生成) + // // 即当对象发生更新时, 调起更新事件, 使用正在观看列表, 向观看状态的ws发送消息(观看状态由ws传递, 断开时取消所有观看状态) + // // 是否为观看状态构建实时更新? + // }) + //} // 这个范围过大, 应当是关注此对象的, 而不是关注 PATCH 频道的, 因此 PATCH 是此对象消息的内容 // 但直接使用对象ID与其它对象重复, 还需要标记对象类型.. @@ -358,29 +365,28 @@ function object_patch(req, res, next) { // 构建将要接受通知的用户队列, 需要去重, 所以使用 map // 由于是作者或管理员修改, 因此不必通知修改者, 要将修改者的id特意从最终列表移出 - let userlist = new Map() - let collect = () => { - userlist.set(doc.uid, true) // 先加入本对象作者 - // 再加入上级关注者. (如果是附属) - if (doc.attach && doc.aid) { } - - // 再加入下级关注者.(这似乎需要作双向绑定才行) - if (doc.attachR) { - // 有哪些类型附属? - // 每个类型有哪些对象实体? - // 此类调用涉及了似乎较为庞大的关系网, 当调用具体对象时, 如何不必对下级作全量查询呢? - // 在顶级加入结构表显然并不合适 - // 下级格式: - // then > star { - // userlist: {} // 只有系统维护的字段, 如果写入, 先转换到 map, 或是直接去重 - // } - // 实际就是这个用户是否关注了这个对象, 如果关注了, - // 如何将上下级关系网中所有用户在不加载大量数据的情况下进行关注状态判定? - // 分离式: 与账户系统解耦, 方便随时分离和改变数据的存储形式 - // - // 如果放了挂载点, 查询上下关联时也要分别读取上下的挂载点, 此时是否对上下也全部加载? - } - } + //let userlist = new Map() + //let collect = () => { + // userlist.set(doc.uid, true) // 先加入本对象作者 + // // 再加入上级关注者. (如果是附属) + // if (doc.attach && doc.aid) { } + // // 再加入下级关注者.(这似乎需要作双向绑定才行) + // if (doc.attachR) { + // // 有哪些类型附属? + // // 每个类型有哪些对象实体? + // // 此类调用涉及了似乎较为庞大的关系网, 当调用具体对象时, 如何不必对下级作全量查询呢? + // // 在顶级加入结构表显然并不合适 + // // 下级格式: + // // then > star { + // // userlist: {} // 只有系统维护的字段, 如果写入, 先转换到 map, 或是直接去重 + // // } + // // 实际就是这个用户是否关注了这个对象, 如果关注了, + // // 如何将上下级关系网中所有用户在不加载大量数据的情况下进行关注状态判定? + // // 分离式: 与账户系统解耦, 方便随时分离和改变数据的存储形式 + // // + // // 如果放了挂载点, 查询上下关联时也要分别读取上下的挂载点, 此时是否对上下也全部加载? + // } + //} // 从待通知用户队列移除修改者id // 执行发送消息