We didn't actually have /org/freedesktop/DBus in the spec, nor did we
explicitly mention the existence of "org.freedesktop.DBus" as an
interface, although it is implicit in the method names.
https://bugs.freedesktop.org/show_bug.cgi?id=51865
Also remove the (double!) requirement that signatures be nul-terminated,
and turn it into a note about the marshalling format.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38252
The "Type Signatures" subsection is basically an introduction to the
type system, so it doesn't need a heading of its own.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38252
In practice, it never works, because the activation helper doesn't
respect environment variables for security reasons.
If you want to vary the search path, alter system.conf instead, to
replace or augment <standard_system_servicedirs/> with your preferred
search path.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=21620
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
I believe that the wording of the spec has always allowed unicast signals,
but most bindings assume that signals are broadcasts, so it seems worth
saying specifically that this feature exists and can be useful.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39450
Reviewed-by: Thiago Macieira <thiago@kde.org>
The spec previously claimed that only messages matching the client's
match rules would be received. This is not actually true: messages
listing a client as their DESTINATION are always delivered (security
policy permitting).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39450
Reviewed-by: Thiago Macieira <thiago@kde.org>
The type system can be used independently, for instance in GVariant
(although GVariant's binary encoding is in fact not the same).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38252
Reviewed-by: Lennart Poettering <lennart@poettering.net>
The org.freedesktop.DBus.ObjectManager provides a standardized and
efficient way of keeping one or more tree of objects synchronized
between one server and several clients.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34869
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
I'm deliberately using a hypothetical API from example.com, rather
than a real API, to avoid perpetuating these over-simplifications any
further than they've spread already:
- "namespaces start with org.freedesktop"
- "namespaces start with org"
- "interfaces are defined by their sole implementation"
- "services have one object implementing one interface"
- "interfaces always behave like classes"
- "interfaces are always noun phrases"
- "there is a freedesktop.org D-Bus API for screensavers"
