docs():copy doc to dir of extension

docs/zh_CN/extension/function.md

@@ -0,0 +1,68 @@
+# Function Extension
+
+In the Kuiper SQL syntax, [many built-in functions](../sqls/built-in_functions.md) are provided to server for various reusable business logic. However, the users still likely need various reusable business logic which are not covered by the built ins. The function extension is presented to customized the functions.
+
+## Developing
+
+### Develop a customized function
+
+To develop a function for Kuiper is to implement [api.Function](../../../xstream/api/stream.go) interface and export it as a golang plugin.
+
+Before starting the development, you must [setup the environment for golang plugin](overview.md#setup-the-plugin-developing-environment). 
+
+To develop a function, the _Validate_ method is firstly to be implemented. This method will be called during SQL validation. In this method, a slice of [xsql.Expr](../../../xsql/ast.go) is passed as the parameter that contains the arguments for this function in the runtime. The developer can do a validation against it to check the argument count and type etc. If validation is successful, return nil. Otherwise, return an error object.
+
+```go
+//The argument is a list of xsql.Expr
+Validate(args []interface{}) error
+```
+There are 2 types of functions: aggregate function and common function. For aggregate function, if the argument is a column, the received value will always be a slice of the column values in a group. The extended function must distinguish the function type by implement _IsAggregate_ method.
+
+```go
+//If this function is an aggregate function. Each parameter of an aggregate function will be a slice
+IsAggregate() bool
+```
+
+The main task for a Function is to implement _exec_ method. The method will be leverage to calculate the result of the function in the SQL. The argument is a slice of the values for the function parameters. You can use them to do the calculation. If the calculation is successful, return the result and true; otherwise, return nil and false. 
+
+```go
+//Execute the function, return the result and if execution is successful.If execution fails, return the error and false. 
+Exec(args []interface{}) (interface{}, bool)
+```  
+
+As the function itself is a plugin, it must be in the main package. Given the function struct name is myFunction. At last of the file, the source must be exported as a symbol as below. There are [2 types of exported symbol supported](overview.md#plugin-development). For function extension, if there is no internal state, it is recommended to export a singleton instance.
+
+```go
+var MyFunction myFunction
+```
+
+The [Echo Function](../../../plugins/functions/echo.go) is a good example.
+
+### Package the source
+Build the implemented function as a go plugin and make sure the output so file resides in the plugins/functions folder.
+
+```bash
+go build --buildmode=plugin -o plugins/functions/MyFunction.so plugins/functions/my_function.go
+```
+
+### Usage
+
+The customized function can be directly used in the SQL of a rule if it follows the below convention.
+
+If you have developed a function implementation MyFunction, you should have:
+1. In the plugin file, symbol MyFunction is exported.
+2. The compiled MyFunction.so file is located inside _plugins/functions_
+
+To use it, just call it in the SQL inside a rule definition:
+```json
+{
+  "id": "rule1",
+  "sql": "SELECT myFunction(name) from demo",
+  "actions": [
+    {
+      "log": {
+      }
+    }
+  ]
+}
+```

docs/zh_CN/extension/sink.md

@@ -0,0 +1,78 @@
+# Sink Extension
+
+Sink feed data from Kuiper into external systems. Kuiper has built-in sink support for [MQTT broker](../rules/sinks/mqtt.md) and [log sink](../rules/sinks/logs.md). There are still needs to publish data to various external systems include messaging systems and database etc. Sink extension is presented to meet this requirement.
+
+## Developing
+
+### Develop a sink
+
+To develop a sink for Kuiper is to implement [api.Sink](../../../xstream/api/stream.go) interface and export it as a golang plugin.
+
+Before starting the development, you must [setup the environment for golang plugin](overview.md#setup-the-plugin-developing-environment). 
+
+To develop a sink, the _Configure_ method must be implemented. This method will be called once the sink is initialized. In this method, a map that contains the configuration in the [rule actions definition](../rules/overview.md#actions) is passed in. Typically, there will be information such as host, port, user and password of the external system. You can use this map to initialize this sink.
+
+```go
+//Called during initialization. Configure the sink with the properties from action definition 
+Configure(props map[string]interface{}) error
+```
+The next task is to implement _open_ method. The implementation should be synchronized to create a connection to the external system. A context parameter is provided to retrieve the context information, logger and rule meta information.
+```go
+//Should be sync function for normal case. The container will run it in go func
+Open(ctx StreamContext) error
+```  
+
+The main task for a Sink is to implement _collect_ method. The function will be invoked when Kuiper feed any data into the sink. As an infinite stream, this function will be invoked continuously. The task of this function is to publish data to the external system. The first parameter is the context, and the second parameter is the data received from Kuiper.
+
+```go
+//Called when each row of data has transferred to this sink
+Collect(ctx StreamContext, data interface{}) error
+```  
+
+The last method to implement is _Close_ which literally close the connection. It is called when the stream is about to terminate. You could also do any clean up work in this function.
+
+```go
+Close(ctx StreamContext) error
+```
+
+As the sink itself is a plugin, it must be in the main package. Given the sink struct name is mySink. At last of the file, the sink must be exported as a symbol as below. There are [2 types of exported symbol supported](overview.md#plugin-development). For sink extension, states are usually needed, so it is recommended to export a constructor function.
+
+```go
+func MySink() api.Sink {
+	return &mySink{}
+}
+```
+
+The [Memory Sink](../../../plugins/sinks/memory.go) is a good example.
+
+### Package the sink
+Build the implemented sink as a go plugin and make sure the output so file resides in the plugins/sinks folder.
+
+```bash
+go build --buildmode=plugin -o plugins/sinks/MySink.so plugins/sinks/my_sink.go
+```
+
+### Usage
+
+The customized sink is specified in a [actions definition](../rules/overview.md#actions). Its name is used as the key of the action. The configuration is the value.
+
+If you have developed a sink implementation MySink, you should have:
+1. In the plugin file, symbol MySink is exported.
+2. The compiled MySink.so file is located inside _plugins/sinks_
+
+To use it, define the action mySink inside a rule definition:
+```json
+{
+  "id": "rule1",
+  "sql": "SELECT demo.temperature, demo1.temp FROM demo left join demo1 on demo.timestamp = demo1.timestamp where demo.temperature > demo1.temp GROUP BY demo.temperature, HOPPINGWINDOW(ss, 20, 10)",
+  "actions": [
+    {
+      "mySink": {
+        "server": "tcp://47.52.67.87:1883",
+        "topic": "demoSink"
+      }
+    }
+  ]
+}
+```
+Whereas, _mySink_ is a key of the actions. The value of mySink is the properties for that sink.