Call remote tasks of service workspace #75
@ -1,6 +1,7 @@
|
||||
|
|
||||
package space.kscience.dataforge.distributed
|
||||
|
||||
import io.ktor.utils.io.core.*
|
||||
import io.lambdarpc.coding.coders.JsonCoder
|
||||
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
import io.lambdarpc.dsl.LibService
|
||||
import io.lambdarpc.dsl.def
|
||||
import io.lambdarpc.dsl.j
|
||||
@ -13,10 +14,8 @@ import space.kscience.dataforge.context.gather
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
import space.kscience.dataforge.data.DataSet
|
||||
import space.kscience.dataforge.data.DataTree
|
||||
|
I do not see, why we need it in the API on the server side the connection should be closeable, not the workspace. Maybe you should rename it to connection and remove inheritance from a workspace? I do not see, why we need it in the API on the server side the connection should be closeable, not the workspace. Maybe you should rename it to connection and remove inheritance from a workspace?
|
||||
import space.kscience.dataforge.distributed.serialization.DataSetPrototype
|
||||
import space.kscience.dataforge.distributed.serialization.MetaCoder
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
import space.kscience.dataforge.distributed.serialization.NameCoder
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
import space.kscience.dataforge.distributed.serialization.TaskRegistryCoder
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
import space.kscience.dataforge.meta.Meta
|
||||
import space.kscience.dataforge.meta.MetaSerializer
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
import space.kscience.dataforge.names.Name
|
||||
import space.kscience.dataforge.names.asName
|
||||
import space.kscience.dataforge.workspace.SerializableResultTask
|
||||
@ -114,6 +113,9 @@ public class ServiceWorkspace(
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
|
||||
public companion object {
|
||||
internal val serviceId = ServiceId("d41b95b1-828b-4444-8ff0-6f9c92a79246")
|
||||
internal val execute by serviceId.def(NameCoder, MetaCoder, TaskRegistryCoder, j<DataSetPrototype>())
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
internal val execute by serviceId.def(
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
JsonCoder(Name.serializer()), JsonCoder(MetaSerializer), j<TaskRegistry>(),
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
j<DataSetPrototype>()
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
)
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
}
|
||||
}
|
||||
|
||||
|
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now. DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming Need to think about better naming
Need to think about better naming Need to think about better naming
Why not suspended? Why not suspended?
Why not suspended? Why not suspended?
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
I thought about I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself.
Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so. Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
|
||||
@ -1,23 +0,0 @@
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
package space.kscience.dataforge.distributed.serialization
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import io.lambdarpc.coding.Coder
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import io.lambdarpc.coding.CodingContext
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import io.lambdarpc.transport.grpc.Entity
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import io.lambdarpc.transport.serialization.Entity
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import io.lambdarpc.transport.serialization.RawData
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import kotlinx.serialization.json.Json
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import space.kscience.dataforge.meta.Meta
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import space.kscience.dataforge.meta.MetaSerializer
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
import java.nio.charset.Charset
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
internal object MetaCoder : Coder<Meta> {
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
override suspend fun decode(entity: Entity, context: CodingContext): Meta {
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
val string = entity.data.toString(Charset.defaultCharset())
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
return Json.decodeFromString(MetaSerializer, string)
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
}
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
override suspend fun encode(value: Meta, context: CodingContext): Entity {
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
val string = Json.encodeToString(MetaSerializer, value)
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
return Entity(RawData.copyFrom(string, Charset.defaultCharset()))
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
}
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
}
|
||||
|
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters? Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
Yes, it already exist, I just forgot about it. Yes, it already exist, I just forgot about it.
|
||||
@ -1,22 +0,0 @@
|
||||
package space.kscience.dataforge.distributed.serialization
|
||||
|
||||
import io.lambdarpc.coding.Coder
|
||||
import io.lambdarpc.coding.CodingContext
|
||||
import io.lambdarpc.transport.grpc.Entity
|
||||
import io.lambdarpc.transport.serialization.Entity
|
||||
import io.lambdarpc.transport.serialization.RawData
|
||||
import kotlinx.serialization.json.Json
|
||||
import space.kscience.dataforge.names.Name
|
||||
import java.nio.charset.Charset
|
||||
|
||||
internal object NameCoder : Coder<Name> {
|
||||
override suspend fun decode(entity: Entity, context: CodingContext): Name {
|
||||
val string = entity.data.toString(Charset.defaultCharset())
|
||||
return Json.decodeFromString(Name.serializer(), string)
|
||||
}
|
||||
|
||||
override suspend fun encode(value: Name, context: CodingContext): Entity {
|
||||
val string = Json.encodeToString(Name.serializer(), value)
|
||||
return Entity(RawData.copyFrom(string, Charset.defaultCharset()))
|
||||
}
|
||||
}
|
||||
@ -1,22 +0,0 @@
|
||||
package space.kscience.dataforge.distributed.serialization
|
||||
|
||||
import io.lambdarpc.coding.Coder
|
||||
import io.lambdarpc.coding.CodingContext
|
||||
import io.lambdarpc.transport.grpc.Entity
|
||||
import io.lambdarpc.transport.serialization.Entity
|
||||
import io.lambdarpc.transport.serialization.RawData
|
||||
import kotlinx.serialization.json.Json
|
||||
import space.kscience.dataforge.distributed.TaskRegistry
|
||||
import java.nio.charset.Charset
|
||||
|
||||
internal object TaskRegistryCoder : Coder<TaskRegistry> {
|
||||
override suspend fun decode(entity: Entity, context: CodingContext): TaskRegistry {
|
||||
val string = entity.data.toString(Charset.defaultCharset())
|
||||
return Json.decodeFromString(TaskRegistry.serializer(), string)
|
||||
}
|
||||
|
||||
override suspend fun encode(value: TaskRegistry, context: CodingContext): Entity {
|
||||
val string = Json.encodeToString(TaskRegistry.serializer(), value)
|
||||
return Entity(RawData.copyFrom(string, Charset.defaultCharset()))
|
||||
}
|
||||
}
|
||||
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming
Need to think about better naming
Why not suspended?
Why not suspended?
I thought about
WorkspaceNodeorWorkerWorkspace. There is alsoDistributedWorkspacebut it is not truly distributed itself.Also
ServiceWorkpaceis good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.I thought about
WorkspaceNodeorWorkerWorkspace. There is alsoDistributedWorkspacebut it is not truly distributed itself.Also
ServiceWorkpaceis good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.