it is rpc can use as tools to communicate with ser...

# kotlinx-rpc

[hafiz]

it is rpc can use as tools to communicate with server for live chat ?

[Alexander Sysoev]

Hi! Yes, you can use streaming capabilities:
https://kotlin.github.io/kotlinx-rpc/features.html#send-and-receive-flows

[hafiz]

@Alexander Sysoev I not familiar with it. Let say for example device A have some delete item from api and call api for update, then device B is it possible to get same data on what device A do?

[Alexander Sysoev]

Yes it is, but what you are talking is not a love chat, but plain network communication. HTTP can do this for you, RPC can do it for you, all depends on concrete needs

[Dumitru Preguza]

@Alexander Sysoev Is there a sample project that would show the use case for building a chat/messaging capabilities using kotlin RPC ?
I'm interested in Telegram like functionality:
• one to one - for traditional chats
• many to many - for chat groups
• one to many - for channels
I think all the use cases are implementable via kotlin RPC, but I'm not sure it's advised to use it over other technologies.

[Alexander Sysoev]

Hi @Dumitru Preguza! Sorry for the delay, I lost your messages in chats.
No, there is no fully available chat project to my knowledge

Advised or not depends on your use-case. As a technology, RPC supports all needed use cases there, but as a library - kotlinx-rpc is not stable and may not fit some particular use cases, so you need to check per your requirements

[Dumitru Preguza]

@Alexander Sysoev Thanks for response! You always say it’s not stable, so I have questions:
When will it be stable?
Do you see this library to fully support these use cases or it was built for something else? I ask because maybe kRPC was not built to be used like this from the library design point of view

[Alexander Sysoev]

Well, design question is more than a library, it is whether you want and can use RPC for your needs. If you can - then you can use the library.

> When will it be stable?
We need to make sure that when we are stable there will not be any major drawbacks in the code, that can't be addressed without breaking changes. We are conducting product research and design meetings for this now, but it's not possible to say for sure or even to give an estimate, because it depends on a lot of factors.

Right now we plan to stabilize gRPC integration first, because the design questions there are much easier than in kRPC. kRPC needs more attention, which we are paying it now with the research.