How close do we want to stay to xo-servers types?

[usbalbin]

There are quite a lot of examples of things in the types sent by xo-server that might make sense in javascript/json but less so in rust. To get out the most out of rusts strong type system some translations might be needed.

I believe there are atleast three categories of types:

• stringly -> strict(er) types. One such example would be ip addresses. In the json object they are simply a string. In rust something like a std::net::IpAddr might make more sense. However, due to not all strings being valid IpAddr'es there is a dilemma - Do we know for a fact that xo-server always gives us valid ip addresses?
• null/undefined -> empty map there are several examples in where xo-server sometimes uses null/undefined for a field and other times an object for that same field. This can be modeled in rust for example by using Option<HashMap<...>>. However it is not clear to me whether the distinction between {}, null and undefined in those cases is of importance. Perhaps something like the address field of Vm could be represented as a plain HasMap not wrapped in any option. This would make it more streamlined to work with. However this is technically a lossy conversion and because of this any serialization again could look different from the original.

TODO describe better and add more cases

[usbalbin]

I believe this might be the source for a lot of the types https://github.com/vatesfr/xen-orchestra/blob/master/packages/xo-server/src/xapi-object-to-xo.mjs