On 2013-04-01 07:15, Kagamin wrote:
It's a pull parser? Hmm... how reordered fields are supposed to be handled? When the archiver is requested for a field, it will probably need to look ahead for the field in the entire message. Also arrays can be discontinuous both in xml and in pb. Also if the archiver is requested for a missing field, it may be a bad idea to return typeof(return).init as it will overwrite the default value for the field in the structure. Though, this may be a minor issue: field usually is missing because it's obsolete, but the serializer will spend time requesting missing fields.
Optional fields are possible to implement by writing a custom serializer for a given type.
The look ahead is not needed for the entire message. Only for the length of a class/strcut. But since fields of class can consist of other class it might not make a difference.
As a schema-informed serialization, PB works better with specialized code, so it's better to provide a means for specialized serialization, where components will be tightly coupled, and the archiver will have full access to the serialized type and will be able to infer schema. Isn't serialization simpler when you have access to the type?
Yes, it would probably be simpler if the archive had access to the type. The idea behind Orange is that Serializer tries to do as much as possible of the implementation and leaves the data dependent parts to the archive. Also, the archive only needs to know how to serialize primitive types.
-- /Jacob Carlborg
