Separating network layer from protocol/processing

[rohitjoshi]

I would recommend creating a separate protocol/processing layer from network layer which will allow for use in different languages and application stacks. e.g. I would like to use TiKV in OpenResty (Nginx + Lua) stack where Nginx async socket needs to be used for network communication.

[doublex]

We would like to use TiKV as backend for Sphinx/Manticore fulltext search.

[siddontang]

Thnaks @rohitjoshi @doublex

But now we have no time to build a C client, we want to build a Rust client at first. then we can provide a C API wrapping Rust, maybe. /cc @hoverbear

If we find the way that C wraps Rust can't work, we will try to provide a pure C API.

[doublex]

@siddontang Yes I understand. And creating a good API is not easy. TiKV is too tempting...

[rohitjoshi]

As long as network layer is separate from protocol/processing layer, it would be great 👍

[rohitjoshi]

@siddontang do we have any timeline on the Rust client API?

[siddontang]

@rohitjoshi

We may plan to start it on Q3. maybe September.

[rohitjoshi]

Any update?

[Hoverbear]

Hi @rohitjoshi you can see that the Rust Client is entered it's final RFC phase: https://github.com/tikv/rfcs/pull/7

Work has begun on it, I expect it will be a bit of time before we can expose a C interface.

[rohitjoshi]

@Hoverbear Great start. Infact, we should be able to expose 'C' binding from Rust client.

[Hoverbear]

@rohitjoshi Indeed that is the plan! We haven't started formally speccing the C bindings yet, but if you'd like to help us review that RFC when the time comes we'd certainly appreciate your input and time.