On Thu, May 09, 2013 at 03:27:24PM -0700, Tyler Hicks wrote: > > dbus [address spec] acquire, # unchanged > > dbus [address spec] -> [address spec], # unidirectional > > dbus [address spec] <- [address spec], # unidirectional > > dbus [address spec] <-> [address spec], # bidirectional
> I'm all for making the arrows match their meaning when read, but I don't > like the idea of arrows pointing in different directions (such as <-). Hrm, the direction is important in this case; it's what differentiates a client able to make any request and receive the responses: dbus bus=session -> , from a server able to respond to any request: dbus bus=session <- , from a program that can send and receive any dbus messages it wants, but can't acquire a name: dbus bus=session <-> , Perhaps these are a bit fringe cases :) but it demonstrate why the arrow would need at least three different 'settings', to represent the three cases of (send, receive, send+receive)... > Also, DBus messages are sent from a connection. They are received on a > connection with a certain path, interface, and member name. This > asymmetry makes the bidirectional arrows confusing when the path, > interface, and/or member name are specified in the rule. Hrm. I hadn't really considered this assymetry with any of the other proposed syntaxes either. Thanks for pointing it out. :) Thanks
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
