[PATCH] No longer need to escape '+' in a D-Bus address

Havoc Pennington hp at pobox.com
Tue Sep 9 21:50:59 PDT 2008


Hi,

On Tue, Sep 9, 2008 at 12:25 PM, Michael Witten <mfwitten at mit.edu> wrote:
>        If the specification has been written so as to make shell
>        scripting easy, then why not write the specification so
>        as to make file-hierarchy paths easy?

The key point really is that we already wrote the specification years
ago, we are not writing it now. As I said before,

  "+" is actually fine from this point of view, but still I think we
  should have a pretty good reason to modify a supposedly-1.0 spec. As
  long as any escaping is required, we haven't really removed any burden
  from most contexts in which addresses are created. Poking around the
  edges seems like all churn no gain.

>        I suppose I am proposing to *extend* the specification,
>        in the sense that it would still be backward-compatible.

The churn is not harmless just because it is likely back compatible;
forward compatibility matters too, due to heterogeneous networks and
app authors only testing with newer versions. And there are multiple
implementations of the dbus spec which may not all get updated at
once.

> Currently though, perfectly good file-hierarchy paths unnecessarily
> morphed into annoyances that entail the discussion of design decisions,
> sifting through abstruse code, and introducing special port-specific
> code.

Well, software development is like that. But really, you said in your
first mail that you already solved it by using another tmpdir; and the
Right Thing is probably something like
https://bugs.freedesktop.org/show_bug.cgi?id=14259 anyway; and another
approach of a 1-line sed operation is available; so I don't think we
have something here worth spending more time on.

I do think it would be worth updating the spec to reflect the (in
retrospect boneheaded) addition of "*" to the chars that need not be
escaped, or at least filing a bug to update it. That was one discovery
due to this thread.

Havoc


More information about the dbus mailing list