structure/caps: serializing and deserializing aren't quite reverses of each other.
This is a suggestion to change the functions priv_gst_structure_append_to_gstring
and _priv_gst_value_parse_string
, which are called by gst_structure_to_string
and gst_structure_from_string
, respectively, to work as closer reverses of each other before calling gst_value_serialize
and gst_value_deserialize
, respectively. Correspondingly, this would allow gst_value_serialize_*
to be the exact inverse of gst_value_deserialize_*
, in particular for GstStructures
and GstCaps
.
For example, gst_value_serialize_structure
will return
priv_gst_string_take_and_wrap (gst_structure_to_string (structure))
and a similar thing happens for gst_value_serialize_caps
. E.g. it would return something like
"name\,\ val1\=\(string\)\"hello\\\ world\"\,\ val2\=\(int\)-5\;"
Note that the "
characters are part of the string.
gst_value_deserialize_structure
is built to receive such a string, and it will essentially call
gst_structure_from_string (gst_string_unwrap (string))
which is an exact reverse of gst_value_serialize_structure
, as you'd expect.
Yet, if the first character is not a "
it will not unwrap the string first, but will straight away call gst_structure_from_string
.
I think the only reason gst_value_deserialize_structure
has this second option (which is an incomplete reverse) is because the string may be essentially unwrapped before calling gst_value_deserialize
. In particular, when a GstStructure
is being read from a string, the library will call _priv_gst_value_parse_value
on the given string, in this case,
(structure)"name\,\ val1\=\(string\)\"hello\\\ world\"\,\ val2\=\(int\)-5\;"
and it will then call _priv_gst_value_parse_string
with the value
"name\,\ val1\=\(string\)\"hello\\\ world\"\,\ val2\=\(int\)-5\;"
with the unescape
option set to TRUE
. What this will do is transform the above string to
name, val1=(string)"hello\ world", val2=(int)-5;
which is equivalent to a call to gst_string_unwrap
(Note, even though _priv_gst_value_parse_string
looks quite different from gst_string_unwrap
, they should function the same in this instance because a GstStructure
string should only contain printable ascii characters, so no octal expansion is necessary.). This is why gst_value_deserialize_structure
needs the second option where the string has already been unwrapped.
I think that, whilst this works, it is a bit messy and it results in the deserialization functions having to accept an altered form. A recent example is the newly added GESMarkerList
s, who's serialization function calls g_strescape
(which will escape \
and "
), but the deserialization does not reverse this because it expects the string to be unwrapped before gst_value_deserialize
is called.
To allow the serialization functions to act as reverses of each other, and not have to worry about whether they receive an escaped or unescaped version of what they serialized, I would suggest that either _priv_gst_value_parse_string
should no longer call _priv_gst_value_parse_string
with unescape
set to TRUE
, or priv_gst_structure_append_to_gstring
should be performing the additional escaping on non-basic types, instead of these serialization functions.
Note, it is already the case that when the string
type is expected to be read from a value, the _priv_gst_value_parse_string
is called with unescape
set to FALSE
. So my own preference would be to never call this with unescape
set to TRUE
and instead let the deserialization process perform the unescaping, as is done with strings.