[PATCH] Fix new DBus API

[Dan Williams]

On Thu, 2011-03-31 at 13:48 -0700, Sam Leffler wrote:
> On Thu, Feb 3, 2011 at 8:42 AM, Dan Williams <dcbw at redhat.com> wrote:
>         On Tue, 2011-02-01 at 18:45 +0200, Jouni Malinen wrote:
>         > On Wed, Jan 05, 2011 at 12:08:02PM +0200, Tomasz Bursztyka
>         wrote:
>         > > "psk" field, in set_network_properties(), was always
>         getting quoted even when
>         > > containing a raw key (64 characters length representing
>         the hexadecimal value
>         > > of the raw key).
>         >
>         > Dan described the design here and it sounds reasonable to
>         allow this as
>         > an alternative approach. However, there is something here
>         that looks a
>         > bit odd to me..
>         >
>         > > @@ -273,11 +286,12 @@ static DBusMessage *
>         set_network_properties(DBusMessage *message,
>         > >             } else if (entry.type == DBUS_TYPE_STRING) {
>         > > -                   if (should_quote_opt(entry.key)) {
>         > > -                           size =
>         os_strlen(entry.str_value);
>         > > -                           if (size <= 0)
>         > > -                                   goto error;
>         > > +                   size = os_strlen(entry.str_value);
>         > > +                   if (size <= 0)
>         > > +                           goto error;
>         > >
>         > > +                   if (should_quote_opt(entry.key, size,
>         > > +                                        entry.str_value))
>         {
>         >
>         > Why is size == 0 an error? I'm not sure it was correct with
>         the previous
>         > quote case either, but now any use of DBUS_TYPE_STRING would
>         trigger an
>         > error if the string is empty. There are number of
>         configuration
>         > parameters for which an empty string is a valid value. Am I
>         missing
>         > something or how is this supposed to work for such cases?
>         
>         
>         That wasn't something I'd recognized originally; what are
>         those
>         properties and what's the motivation for them?  Are these
>         things where
>         just the presence of the property is important, but the actual
>         value
>         isn't know at this time, or...?
>         
> 
> 
> This seems to have been dropped.  The raw PMK fix that triggered this
> exchange never got committed and is useful so can we resolve the issue
> with zero-length strings?

I'm not sure I follow.  In what situations is a zero-length string
useful as a property?  I'm not saying it's not useful, I'm just trying
to figure out what problem this fix is trying to work around?

dan