[RFC] should we ignore unknown key in match rule?

[Yang Chengwei]

Filed a bug to track this feature request.
https://bugs.freedesktop.org/show_bug.cgi?id=66114

--
Thanks,
Chengwei

On Mon, Jun 24, 2013 at 12:36:31PM +0100, Simon McVittie wrote:
> On 24/06/13 08:26, Yang Chengwei wrote:
> > Hi List,
> 
> No need to Cc me - oddly enough, the person who has done most of the
> D-Bus releases in the last 2 years does read the mailing list :-)
> 
> > I just found that the *new* dbus-monitor can't run with the *old" 
> > dbus-daemon.
> 
> "Old" here means 1.4, which is older than the current stable branch. I
> don't support older-than-current-stable D-Bus versions, except for
> non-intrusive security fixes.
> 
> > Error: Unknown key "eavesdrop" in match rule
> > 
> > This is cause by "eavesdrop" is newly added to dbus to fix an
> > issue: https://bugs.freedesktop.org/show_bug.cgi?id=37890
> 
> The right way to fix this would be to do the AddMatch with eavesdrop,
> and if it fails, try again without it - like Bustle does[1]. I'd
> accept a patch that did this, if you think compatibility with D-Bus
> 1.4 is really that important.
> 
> [1] http://cgit.freedesktop.org/bustle/tree/c-sources/pcap-monitor.c
> 
> > Again, if an implementation sees a header field code that it does
> > not expect, it must ignore that field, as it will be part of a new
> > (but compatible) version of this specification.
> 
> This is specifically talking about header fields: if it was meant to
> be about other constructs, it would say so.
> 
> > So I think it's applicable to the match rule, say: ignore unknown
> > keys in match rule.
> 
> If you think the D-Bus Specification should have similar wording about
> match rules too, that's a reasonable request to consider.
> 
> In general, adding keys to a match rule makes it narrower, so in
> general, adding an unrecognised key would result in the client
> receiving more messages than it had intended to. In principle, clients
> should consider match rules to be advisory, not mandatory, so in
> principle, it should be prepared to ignore those extra messages. In
> practice, there have been clients that are buggy if they receive
> unwanted messages.
> 
> So, it's a question of which of these is more valuable:
> 
> * making it fractionally easier to add more match rule keys (clients
>   wouldn't have to "guard" their AddMatch calls, if they can depend on
>   a D-Bus version new enough that it ignores unknown keys)
> 
> * minimizing how much we break the expectations of clients that wrongly
>   expect their match rules to be exclusive
> 
> If we make this change to the specification, it won't change the
> behaviour of currently-deployed copies of D-Bus, so clients using new
> match rules will *still* have to "guard" AddMatch calls until they can
> depend on a new enough D-Bus version that it has the "ignore unknown
> match rules" behaviour. I think that's the sort of behavioural change
> that should go through a development branch (1.7), meaning it won't be
> widespread until 1.8.
> 
>     S
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130625/1fcf680a/attachment.pgp>