On Mon, 8 Jul 2024 at 14:12, Fujii.Yuki@df.MitsubishiElectric.co.jp
<Fujii.Yuki@df.mitsubishielectric.co.jp> wrote:
> The best thing about Approach2 is that it lets us send state values using the existing data type system.
> I'm worried that if we choose Approach2, we might face some limits because we have to create new types.
> But, we might be able to fix these limits if we look into it more.
>
> Approach1 doesn't make new types, so we can avoid these limits.
> But, it means we have to make export/import functions that are similar to the typsend/typreceive functions.
> So, we need to make sure if we really need this method.
>
> Is this the right understanding?
Yeah, correct. To clarify my reasoning a bit more: IMHO, the main
downside of implementing Approach1 is that we then end up with two
different mechanisms to "take data from memory and serialize it in a
way in which it can be sent over the network". I'd very much prefer if
we could have a single system responsible for that task. So if there's
issues with the current system (e.g. having to implement
typinput/typoutput), then I'd rather address these problems in the
existing system. Only if that turns out to be impossible for some
reason, then I think I'd prefer Approach1.
Personally, even if the Approach2 requires a bit more code, then I'd
still prefer a single serialization system over having two
serializiation systems.
