Closed ChrisGreenaway closed 7 years ago
The layering on the client side of entities looks like this.
Yellow is Voltron, blue is entity implementation. Message flow goes up and down the stack. If we wanted getEntityConfiguration()
to return a type, we'd need to move the config de/serialization logic to the MessageCodec. This would also mean a change to EntityServerService.create(Active|Passive)Entity(ServiceRegistry, byte[])
.
I guess the central question right now is that Configuration bypasses MessageCodec and is negotiated between EntityClientService and EntityServerService. Should this be the case or should it be moved?
Something feels weird in the interactions there indeed. I understand that Entity
configuration (de)serialization does not need to be handled by the message codec. Maybe simply introducing a configuration codec would resolve the problem. As it can then be used by the EntityEndpoint
the same way it uses the message codec.
Would that make sense?
And if we go forward with that, I agree it means introducing one more generic type and changing the create*Entity
method signatures.
Another scheme could be to simply lift the configuration related methods from Entity*Service
into a different interface, which they would extend. And then have the EntityEndpoint
use that interface and the message codec. That enables segregation from the client side and does not change fundamentally (IMO) the way an EntityEndpoint
is materialised.
Another possibility, combine the MessageCodec and configuration codec into one interface. So there would be encode and decode methods for message and response (as now) and encode and decode methods for configuration.
We will re-open at a later date if the need arises.
The getEntityConfiguration() method on EntityClientEndpoint returns a byte[] which must be deserialized to recover the configuration.
Can we have a method that returns the configuration? After all, Voltron knows how to do the deserialization - there's a deserializeConfiguration method on EntityClientService.