本设想是对前一篇的具体化。
本设想可以视作网格计算（grid computing）的一个实现尝试。
在当今计算早已离不开网络化、分布式，随着流媒体等流数据(stream data）的增加流式处理（stream processing）越来越重要。传统的储存—获取模式无法满足即时性高、变化快的“大数据”。
虽然流数据处理框架有很多，但似乎主要是第三方平台，比如AWS、阿里云，他们的服务我们都有所了解或耳闻。我现在设想另一个角度：提供一种可跨平台移植的框架，作为第三方平台的补充，作用是优化集群/协议集团内的资源调配以实现良好的实时数据传输和处理效果。
集群/协议集团「正式概念不知道是什么」指的是接受这个协议/框架的所有节点，比如一个host和10个client都接受这个协议那他们就是一个协议集团，集团内成员及协议可以经常变化。
一个已有情形：某种流数据(音视频/股票信息/传感器信息etc) 需要经即时或轻度延迟处理后传递到多个终端，不同终端需求不完全相同，比如某个公司在不同地方的分支，业务差别导致当时所需数据不尽相同。
在总服务器压力过大的背景下，把计算任务分散到途径的节点上，在转发的过程中预见性地(根据网络状态、算力性)处理。比如，租车公司有巨大的实时车况数据，有的终端只需要获取所有车的位置，有的则需要其他数据，有的在此基础上还需要实时处理后的东西：假设只有5个节点，一个主机加4个终端，第一批数据从Z传到A和B，需要完成计算a1和a2后去C和D(A、B自己分别也需要a1和a2)；A与C间连接速度，不行但A算力很大，就让完成a1计算的同时把处理后数据传给C；B和D连接特别好但都算力有限，于是B第一时间向D传输同时一起计算a2并共享结果。
以上情形看起来正式（广义的）云计算服务商可以完全解决的，所以数据及计算交给它然后分发不就行了吗？我认为存在一些目前还不完全适合的情形：一是不同硬件平台的异质性加上高即时性要求，二是信任度和安全相关的。前一点比如智能耳机在一些环境下的情况，假设老李佩戴有助听功能的智能耳机，老李本人有高频损失（老年人很普遍的情况），声音要经过一定频率调整，但此时老李正在一个博物馆参观，要用耳机接受展板上的讲解语音。这段语音需要经过处理才适合传入老李耳朵，而展板上的信号发射设备与老李耳机有一定平台差异。
此时一个解决方案是耳机内的智能处理模块（接受原音频，处理后播放），一种是上天（云）交给第三方平台然后经许多结点传回老李耳机。第一种方案面临处理接口（音频格式差异等）问题，而且更严重的是，受制耳机自身的运算能力（假设老李一边听讲解，同时耳机还要处理其他信号，忙不过来）；放到工业领域，比如很多传感器数据量大，这种情况会导致个别设备超负荷。避免把鸡蛋都放到一个篮子里计算。第二种方案呢，中途经历的节点很多，实时性容易受严重影响，同时需要向第三方平台提交计算的内容——即程序，大大增加了数据传输量。云计算平台被很多用户喜爱，降低网站成本的一个根本原因是计算的服务是反复使用、普遍的，但随着流数据的复杂化矛盾会增加。云平台提供服务的本质是程序无关的CPU、存储和内容分发网络。
我想到了另一个方法：借用兜里手机的CPU，让讲解牌发出的音频部分或全部地由手机完成计算，手机里储存有耳机上用到的程序可以直接调用，然后经过不足一米半的距离传到耳机里播放就行。
恰好，当天经过远程诊断，5G医疗中心的专家发现老李的听力情况最近有变化，要调整助听模块的功能，于是把整个更新的模块传到老李手机里，再慢慢转到耳机里。当时恰逢老李在外面比较嘈杂的环境，需要先更新助听模块中的“室外模式”子模块，理想的情况下是更新后即用。（类似地，工业物联网中的实时更新——机器人的机器视觉模块更新的同时就立刻用到流水线上。）
像刚才a1、a2之类的计算有很多，经常变化，计算模块如果存储在各节点内(DLL的思路)会造成很大的更新和协调成本。
总结一下问题，就是：1 计算资源需要多平台动态共享、调用 2 计算方法——程序需要不断变化，而且迅速在其他平台使用，使用后价值大大降低甚至可以抛弃。后一点的一个例子是我感觉App更新有一个“update hell”，很多功能可能就用几次而且也不复杂，但非要更新整个app。
基于这两个角度我的想法是：用协议和中间件传输“临时程序模块”(二进制文件到达后组装成与app内部接口对接的数据结构)，这些临时程序模块可以跟流数据结合实现压缩式结合传输。
总的设计思想是：即时性第一，问题最大最不稳定的是网络，CPU运算能力在各平台间共享，让数据和程序模块/算法一起传输。
也许未来会出现一个场景：“借用一下你手机，帮我手机上的这个程序加速。”这是一种基于网络传输的同时共享软硬件的思路，也许未来我们很多时候都不必带着性能越来越强的手机、平板、笔记本，带一个屏幕终端与办公室里诸多有CPU的智能设备联网，绝大部分计算由这些设备分工完成（一些计算甚至精细地被分到电灯、空调、门禁系统的多余算力里面）。
而多异质平台上的临时程序使用需要传输程序，确切说是“计算片段”——数据加上通用平台（微内核或更简单的计算框架）可快速接受并运行的小程序。
对数据通信来说，多数情况下数据本身作为二进制数据流传输，数据本身包含的信息是解码之后获取的，这就要设计面向应用层（？）的新协议或对寻找合适的已有协议/并改进。
具体技术应该多考虑web客户端的设计思路（参考杨扬关于前后端置换的说法[1]），简化与统一相结合。类似HTML5取代flash。
具体开发内容的设想：1 面向异质边缘设备资源共享（特别是计算能力共享）的方案 2 适用不同平台的数据结构化的“原型程序”。
内容的2再解释一下，就是软件版的“精简指令集”或“虚拟程序”，比如手机和一个单片机都可以接受的软件框架——把可能用到的（暂时限于音视频处理）的常用程序、算法以这个框架能接受的数据结构传输并由这个框架来运行。这个原型程序/平台用与硬件底层对接良好的高级语言（如Java/C）写成，与操作系统和硬件的对接是各平台层面的（软件对软件的“编译器”），而常见音效、降噪等常用模块可能转换成线性滤波器、傅里叶变换等软件层面更底层的结构，后者再转换成软件“指令集”，这些指令高于加减乘除等基本硬件运算，但低于傅里叶变换。
参考
1 现代 Web 开发的现状与未来 - 2017年演讲在回复里 https://0xffff.one/d/445/2
2 一个关于流媒体（音频）协议项目的设想