> Indeed, perhaps one could develop an elaborate system where in the schemas, we could annotate certain fields as being relevant to certain servers. Anywhere else, those fields would be unavailable (but passed through without modification or validation). If you needed the fields in a new place, you change the annotations.
I don't think it has to be elaborate. What I was thinking was something more like, in pseudo-C#:
// the framework's general channel type from which messages are read
public interface IChannel
{
T Read<T>() where T : interface;
}
// clients declare the interface they operate on:
public interface IClientFields
{
public int Foo { get; set; }
public string? Name { get; set; }
}
...
// client middleware function
Task MiddlewareFn(IChannel chan)
{
var client = chan.Read<IClientFields>();
... // do something with client before resuming at next stage
}
The client's interface type T must simply be a structural subtype of the underlying message type. As long as the underlying format is somewhat self-descriptive with a name and type map, you can perform the necessary checking that only applies locally to the client. Nothing fancy, and the required fields that client cares about are still there and the rest are ignored because they're never referenced. This could return an interface that contains a series of offsets into the data stream, which I believe is how capnproto already works.
Are you saying that each service would need to declare, separately, the subset of fields they operate on, and make sure that those fields are always a strict subset of the overall set of fields the protocol contains?
This essentially means declaring the same protocol multiple times, which seems like a big pain.
Assuming the service is not operating on the whole format, then it's already implicitly depending on the presence of those fields and also implicitly depending on the fact that they are a strict subset of the overall set of fields in the protocol. I'm not sure why making this fact slightly more explicit by having the client add a single interface would be a big pain.
In principle, this also enables type checking the whole pipeline before deployments since the interfaces can be known upfront rather than latent in the code.
I said a single interface per client, where I'm using "client" as a stage in the pipeline. Each piece of middleware that plugged into this pipeline already implicitly depends on a schema, so why not describe the schema explicitly as some subset of the underlying message?
I don't think it has to be elaborate. What I was thinking was something more like, in pseudo-C#:
The client's interface type T must simply be a structural subtype of the underlying message type. As long as the underlying format is somewhat self-descriptive with a name and type map, you can perform the necessary checking that only applies locally to the client. Nothing fancy, and the required fields that client cares about are still there and the rest are ignored because they're never referenced. This could return an interface that contains a series of offsets into the data stream, which I believe is how capnproto already works.