Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (fc900e5) 16.80% compared to head (f293fd9) 16.80%.

❗ Current head f293fd9 differs from pull request most recent head f37bce1. Consider uploading reports for the commit f37bce1 to get more accurate results

@@            Coverage Diff            @@
##             master    #4560   +/-   ##
=========================================
  Coverage     16.80%   16.80%           
  Complexity     1626     1626           
=========================================
  Files           749      749           
  Lines         28683    28683           
  Branches       2487     2487           
=========================================
  Hits           4821     4821           
  Misses        23408    23408           
  Partials        454      454           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Seeing that they are all paired Source-Sink, I thought of a little confusion I have recently.

First of all, it is definitely not that all components are suitable for developing Source and Sink. Otherwise, it would only seem a bit useless when we force it out.

But then again, for example, if a component that is only suitable for developing Sink has already been completed, the data that the Sink obtains is often very specialized. If we don't develop the Source, it is not easy to make EventMesh produce such data.

These create a contradiction. I hope the community can answer my confusion.

看到都是成对的Source-Sink，想到自己近来的一点困惑。 首先肯定不是所有组件都既适合开发Source，又适合开发Sink。否则的话，强行开发出来，只会显得有些鸡肋。 但是话又说回来，比如已经完成了一个只适合开发Sink的组件，往往该Sink获取的数据是很特异化的，如果不开发Source的话，让EventMesh产出这样的数据并不容易。 这就出现了矛盾，希望社区帮我解答一下。

1.目前并没有说source和sink要配套的出现，现有的模型就是为了让source与sink进行解耦的
2.sink获取的数据很特异化，我不是很明白，比如dingding的sink connector，那它对应的source connector可以有多种，可以是邮件的source\github 的webhook的source\promethues source 等等

1.目前并没有说source和sink要配套的出现，现有的模型就是为了让source与sink进行解耦的

是的，也正因为这个才有我当前的困惑。

2.sink获取的数据很特异化，我不是很明白

比如钉钉需要ConnectRecord有特定的extension