I merged a bunch of stuff into my local master this weekend, but before I push I want to ask a bunch of things, since a lot of stuff I haven't merged until I understand its motivation. SPOILER: at the end I suggest we create a XomSerializable interface that provides the API you desire, as distinct from the existing one (which aims to be small and restrictive like json-glib's).
Unknown properties and types, errors and signalsIn Serializable you create signals for unknown type and unknown properties, that seem to correspond with a couple of the errors in SerializationError. Is the idea for them to replace or supplement those exceptions, allowing a programmer to improvise a solution? Or, based on its usage in SerializableTest.vala, is it supposed to replace deserialize_property () (the user defines their own serialization functions and connects them instead of implementing named ones in the interface?)
Right now it seems a bit redundant with what {de,}serialize_property () provides. I can see that it might be useful if the types that a program uses might change and it doesn't want to have to try to recover simply from a GError (that is, the signal provides the GXmlNode node and GParamSpec spec to work with).
serialized_xml_node_value, node_name, property_use_nick
property_use_nick: Why are you interested in using the nickname for the property? I see it getting used in SerializableObjectModelTest.vala. Is it only for SerializableObjectModel (SOM) serialization?
node_name: With node_name, is there any particular reason why you want to change the node name from Object? In SerializableGeeTreeMapTest.vala, the node_name () overrides are just the name of the type but in lower case, and the original type name would appear in the otype attribute anyway (<Object otype="SpaceContainer">).
serialized_xml_node_value: is this just for SOM serialization?
You seem to prefer abstract methods with a second default implementation method over using virtual methods in the interface. Is there any reason why?
Mostly seems to set up ignored_serializable_properties and unknown_serializable_property. Can we just do that in the property's construct {} section instead, and eliminate this? I feel like other serialization and deserialization tasks for a Serializable object can be done in {de,}serialize_object
Naming
I mentioned in the previous e-mail that I'm hoping to keep naming consistent with the other serialization API used in GNOME, json-glib, for a consistent experience. I'm inclined to thus keep things like {get,set}_property, find_property and list_properties the same names.
An ideaI feel like a lot of choices in your work come down to supporting the XML Object Model style of serialization. Would you be OK if we created XomSerializable (or XOMSerializable) that embodied those? That way, the existing Serializable work would continue to agree with json-glib's serialization approach, and would continue being minimal (things I've merged locally from your work include things like the properties blacklist, interface methods for object-level serialization instead of just property-serialization, and for serializing/transforming values by types). The two can continue to share code and implementation (like in Serialization's serialize_object () and deserialize_object ()).
If we create the XomSerializable, I'll also be fine committing just about whatever you want to it (as long as it doesn't break the API of other stuff or strangely pollute the namespace :D). How does that sound? We could create a subdirectory in the source tree, like gxml/xomserialization/ or gxml/xom or something. (I've been thinking of moving serialization into its own tree already, just because of the growth of serialization files :D)
