20210522系统 - ziyouzy/2021blog GitHub Wiki

可以把如下两个结构定义成“系统”:

go func(){
    for temp := range ch{
      //do sth for temp
    }
}()

go func(){
    for{
        select {
        case temp1 := <-ch1:
           //do sth for temp1
        case temp2 := <-ch2:
           //do sth for temp2
        case connect := <-ch3:
           ch<-connect
        }
    }
}()

其实可以这样来定义这一切：
管道是用来处理数据流动的工具，管道与管道则是通过上述“系统”实现相互连接的
而“流动”的原则之一是不能逆流，我这两天的bug其实就是逆流引起的：
是三个系统之间发生的问题导致的，首先产生了一个RIVER_NEW的需要被“流动”于是借助了EEBox“系统”并首先流向了EEbox系统的Events管道
流入后，识别出这数据需要发送至flutterUI客户端，于是为了实现数据“向下游流动”，因此又去借助了usrio808_sender的“核心系统”
然而usrio808_sender的“核心系统”又企图把数据流回EEBox系统了，这就是逆流

其实之前的思路一直是正确的，我设计出了fromusrio808reader toflutteruiwriter就是一个很成功的例子，数据在这两大系统与两大系统内部的小系统内传播，或者说是向下游流动

绝对不能反向

而eebox却违背了这个初衷，我需要继续重构与完善

Errors绝不能发送给前端
Events可以发送给前端，也可以不发送给前端
从eventbox发来的数据无论接收端是哪个writer，如果这些数据出错了就只能被转化为新的events了(大多数情况会转化为error)，这个新的events虽然也会发送至eventbox，但是禁止把他设计成一个需要发送给前端的event
在writer类型的river-node或者是writer类的river中
即使是在处理非eventbox的数据，那也是禁止在此生成“需要被发送至客户端”的events的，只能生成“只记录日志的events和（只记录日志的）errors