From: martin@martinorr.name (Martin Orr)
Date: Thu, 03 Feb 2011 00:18:20 +0000
Subject: [refpolicy] [PATCH/RFC 2/19]: patch set to update the
	git	reference policy
In-Reply-To: <1296515714.18286.79.camel@tesla.lan>
References: <1295829832.3862.61.camel@tesla.lan>
	<4D3D8BB5.4010501@gmail.com> <4D4704F2.7080604@tresys.com>
	<1296515714.18286.79.camel@tesla.lan>
Message-ID: <20110203001820.80983f9echanzo8w@webmail.tuffmail.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon 31 Jan 23:15:14 2011, Guido Trentalancia wrote:
> The DBus send_msg issue is the probably the main change introduced by
> the set of patches that I am proposing.
>
> The issue is very wide and needs careful approval. It's not limited to
> this [2/19] patch/thread at all. It is mainly a style issue, but it's an
> important one.
>
> In any case, [2/19] and [8/19] are perhaps the most relevant places
> where you can provide a definite direction on this (in short, can we
> really talk about an hypothetical DBus "chat" throughout all refpolicy
> and model interfaces accordingly to such assumption when on the other
> hand the elementary data-flow in DBus is constituted by a
> uni-directional message called "signal" ?).

I think that it is often better to think about "chats".  Often one  
process A (e.g. consolekit or setroubleshoot) provides a service which  
many other processes B can use by sending a DBus message to A.  A only  
sends messages to B after getting messages from B.

In this case, I think it is likely to be more maintainable if each  
module B uses A_dbus_chat, instead of putting a big list of all the  
possible B into module A.  I do not care strongly about it however.

-- 
Martin Orr