You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently server implementations use server handler builder to process incoming calls using the existing stream observer api. This requires a lot of adapter code just to map coroutine behavior to the existing stream observer call back.
It should be possible to implement ServerCallHandler and emit its usage in the generated code. This gives us the ability to not only improve performance but map the coroutine apis closer to the call level.
At the moment it is difficult to expand the kroto API. With access to the call, we could potentially allow users to pass execution parameters via a call wrapper type. This would allow the customization of the following:
Currently server implementations use server handler builder to process incoming calls using the existing stream observer api. This requires a lot of adapter code just to map coroutine behavior to the existing stream observer call back.
It should be possible to implement
ServerCallHandler
and emit its usage in the generated code. This gives us the ability to not only improve performance but map the coroutine apis closer to the call level.At the moment it is difficult to expand the kroto API. With access to the call, we could potentially allow users to pass execution parameters via a call wrapper type. This would allow the customization of the following:
CoroutineStart
coroutineContext
Call wrapper example:
The kroto implementation of
ServerCallHandler
would be able to check for this type explicitly during method invocation and use the parameters providedThe text was updated successfully, but these errors were encountered: