Media source extension api

@realpg 对，其实用 session 类型的 cookie 存东西就行，用户关了所有 tab 自动被清掉。用 sessionStorage 存的话要考虑跨 tab 共享问题，解决完这个问题，行为就和 session cookie 一致了。

利用好了，根本就不要什么 logout 接口。

@realpg 依赖 session 类型的 cookie 然后捏？怎么在合适的时候调用 logout 接口？所以说要改实现，因为没法保证调用后端的 logout 接口。

还有哦，sessionStorage 和 session 类型的 cookie 行为不一致。sessionStorage 不跨 tab.

@realpg 这还不奇葩？这跟动态网页有什么关系？你哪怕是 windows 客户端也不能保证用户退出就一定能调用到服务端的 logout 接口。我强杀进程，直接强制关机等等，都可能导致客户端直接就消失不调用你的 logout 接口。

logout 是要干什么？统计在线人数么？还是释放啥资源还是什么？非要强依赖客户端在线与否，那只能建立 socket 或者让客服端发心跳。期望客户端恭恭敬敬给你调用 logout ，那只能说无法保证。

下划线开头的变量名在 ES6 之前的版本中并没有实际意义，强行引入额外的语义只会挖坑。并且当时已经流行的社区 js 模块化方案 commonjs requireJS 都是显式声明导出的变量。显式声明导出也符合从无模块化到有模块化迁移的过程。那时候用闭包模拟模块肯定没法做到默认导出模块顶层作用域。

那你先列举一下默认导出顶层作用域中的变量比默认不导出有什么优势。顶层变量不想导出还得专门引入一种语法来声明不是？像 python 一样用下划线么？还是用其他关键字？结果和默不导出不就是一回事吗？

let a=1; //不导出
export let b = 2; //加关键字导出，和 java 的 public 岂不是一样？
export {a}; // export 还可以导出已有内部变量

不妨想想为什么登出一定要调用 logout 接口，不调用会有什么后果？是后端有资源要释放么？用户浏览器直接崩也是可能没机会调用 js 的 unload 的，所以关键逻辑不能依赖 logout 接口。

@v2eb 关闭和刷新分不出来的，只有一个 tab 一刷新结果登出了？

就是典型的 switchMap 场景，自动 unsubscribe 上一次产生的流，自动切到最新的流上去。

id$ = new Subject();

price$ = id$.pipe(
switchMap(id => getPriceById(id))
)

// merge + map 很干净，省一个 subject
isLoading$ = merge(
id$.pipe(mapTo(true)),
price$.pipe(mapTo(false))
);

getPriceById 需要返回一个 observable, unsubscribe 时 abort 请求即可。

切商品直接 id$.next(newId), price$ 和 isLoading$ 会自动更新。上一次没完成的请求 switchMap 会自动 unsubscribe ，简直毫无负担。

对，rxjs 下 switchMap 很简单。

桥接正解。

@nothingistrue js 也有的，不过不是线程，是 worker ，更像是进程就是了，而且没法直接共享内存，要借助 shared buffer, 但也是可以以阻塞模式 wait 对方，等对方 notify 再继续跑的。也就是借助 Atomics 相关的 API 。一些库可以利用这个把复杂异步操作封装进另一个 worker ，对外呈现同步阻塞的调用方式，很有意思。

开一个 worker 然后 shared memory, 然后用 Atomics.wait 挂起等待 worker 完成请求。。。。

这不就是类似装树莓派的方法嘛，x86 下应该也有类似的 linux 发行版？

树莓派是完全可以用 tf 卡配置好 wifi 或有线网络，打开 ssh ，vnc 等服务，插上卡一通电直接 ssh 或者 vnc 连接就行了。

@acbot 你把编译生成的文件和代码想象成传统编译语言生成的产物，就不会纠结它生成了什么代码，生成的文件用了什么命名规则了。那些重要吗？并不。你把整个 dist 目录当作一个整体，给个服务器一 host ，浏览器里就能跑了，这就行了。debugging 自有 source mapping 处理。就跟 C 语言编译生成了什么样的二进制文件内容，我们并不关心，只要它确实还原了源代码的意图，就 ok.

4. 一个网站一天一发布甚至一天发布好几次，发布一次就人为改一次名称么？显然不现实。就算改你打算怎么起名字？ script_v1 script_v2 么？ content hash 有什么不好的。这都是 web 发展这么多年来大家总结出来的行之有效的方案。

@Suigintou 看语境吧，离了语境什么都可以变得模棱两可。

英语的 you 不分你还是你们，叔叔舅舅大姨姑妈也不分呢。

@Eyon

"没有设计用户系统，所以我就不知道这个东西的意义在哪里。"

这就是问题所在啊。不同系统对鉴权的要求不一样。

你开了家图书馆，读者进来只要到服务台领一张通行证跑到入口处，保安一看通行证，上写天王盖地虎，就让你进了。这就是你在用的认证。下次你知道口令了，自己弄了张一样的纸写上天王盖地虎，保安照样让你进。

你觉得这样不对是吗，那是因为你的图书馆不应该用这种最简单的方式呀。

HTTP authorisation 并没有限制你只能用天王盖地虎这种对口号的方式鉴权。你可以有用户系统，鉴定用户名密码，每次报用户名密码太烦了，那可以鉴定一次然后发临时通行证。没有用户系统还要对任意用户提供服务，那要哪门子 authorisation 。

Http 协议只是提供了一种建议的鉴权方式，它方便你的服务端去鉴别 user agent 发起的这次请求是否符合某些身份要求。在 Http 协议的概念里是没有浏览器这种东西的，只有 user agent, 或者说 http client 端。