On 26.07.2018 12:37, Tanu Kaskinen wrote:
On Sun, 2018-07-22 at 21:11 +0200, Georg Chini wrote:
On 22.07.2018 17:48, Tanu Kaskinen wrote:
On Sun, 2018-07-22 at 16:02 +0200, Georg Chini wrote:
On 21.07.2018 20:17, Tanu Kaskinen wrote:
On Mon, 2018-04-09 at 19:35 +0200, Georg Chini wrote:
The patch adds the possibility to escape curly braces within parameter strings
and introduces several new functions that can be used for writing parameters.
For writing, the structure pa_message_param, which is a wrapper for pa_strbuf
has been created. Following new write functions are available:
pa_message_param_new() - creates a new pa_message_param structure
pa_message_param_to_string() - converts a pa_message_param to string and frees
the structure
The function pa_message_param_write_string()
has a parameter do_escape.
Why not do escaping always?
Because what you are writing as a string may be a list that you have
prepared
previously. Then you will not want escaping. You may for example create
a list
from an array and then insert this list as one string into the final
parameter list
or have a function that converts a certain structure to a parameter
string and
then write the result of this function as one element of the final list.
My mental model is that parameters have types, list type is different
than string type, and write_string() is only meant for writing values
of the string type.
Can you add a write_raw() function?
Yes, this is done in patch 7. But the raw write function differs from what
write_string() is doing. write_string() writes one element of a list,
that is
it encloses the string in braces. The raw write function is intended for
situations where you can't write a complete element with one write, so
it does not add any braces. I am still of the opinion, that a structure
or array converted to a parameter string is a string, so writing something
like this should be done with write_string().
They are different kinds of strings, different abstraction levels. When
you're writing an array "as a string", in that context it's just a C
string. write_string() with escaping deals with strings in the "message
params type system". I don't know if this makes any sense to you.
Probably not... In any case, the do_escape flag seems unnecessary
complexity to me.
The alternative would be a function to write an unescaped string in
addition to the write_raw() function. If you don't like the flag, would
you be OK with a write_unescaped_string() function? I think it is just
more comfortable than using write_raw().
Also writing unescaped strings in situations where escaping is not necessary
saves the overhead of looping over all the characters.
core-util already contains pa_unescape() that does the same thing more
efficiently (if you drop the single quote thing).
pa_unescape() currently does not do the same thing. It removes all
escape characters, while I only want to remove the characters
I actually introduced (those before { or }).
I can however modify pa_unescape() to take the same arguments
as pa_escape().
I don't see the need for being selective when unescaping. Nothing
breaks if all (except escaped) backslashes are stripped.
You are right, if previously all backslashes in the original string
have been escaped, nothing will break. I was still thinking of the
old solution where I did not escape backslashes.
+
+/* Read functions */
+
/* Split the specified string into elements. An element is defined as
* a sub-string between curly braces. The function is needed to parse
* the parameters of messages. Each time it is called returns the position
* of the current element in result and the state pointer is advanced to
- * the next list element.
+ * the next list element. On return, the parameter *is_unpacked indicates
+ * if the string is plain text or contains a sub-list. is_unpacked may
+ * be NULL.
is_unpacked looks like unnecessary complexity.
pa_message_params_read_string() should always unescape the value.
It may be possible, that the string you read is a list. Consider the
following
parameter list: {string1}{some nested structure}{string2}. You can now
read this list as three strings and then continue to read the elements of
the nested structure from the second string. You might even create a
function
that takes a string and outputs a structure. So you are not forced to go
to the full depth of nesting on the first pass. This makes it much easier
to handle deeply nested parameter lists. For me this behavior is an
important
feature and I do not want to drop it. See also my comment on why I do
not always want escaping.
Doesn't split_list() already allow this, why do you want to use
read_string() to do the same thing as split_list()?
read_string() and split_list() are very similar and we could live
without read_string(). It is provided as a counterpart to write_string()
and for convenience additionally does the unescaping if necessary
like write_string does the escaping.
I don't see why this is a problem. It depends on the context which
is the better function to use.
Again, in my mind a structure is not a string, they are different
types, and I think read_string() should only deal with the string type.
is_unpacked makes the API more complicated, so I'd like to get rid of
it.
I don't see your point. is_unpacked is not part of the read_string()
arguments
or return value. In split_list() it is definitively needed to indicate
if the returned
string (in the C sense) contains another list. I can imagine many
situations where
you might either pass an array or just a single value or even NULL.
is_unpacked
allows to differentiate between the situations. And I don't think that a
boolean
return value is adding significantly to the complexity of a function,
especially
since passing NULL is allowed if you do not care for the value.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
