From: guido@trentalancia.com (Guido Trentalancia)
Date: Wed, 08 Aug 2012 16:19:26 +0200
Subject: [refpolicy] [PATCH] oidentd fixes
In-Reply-To: <1344432444.2306.37.camel@d30.localdomain>
References: <1344365757-12896-1-git-send-email-dominick.grift@gmail.com>
	<50226587.5010507@tresys.com>
	<1344432444.2306.37.camel@d30.localdomain>
Message-ID: <5022756E.6060505@trentalancia.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/08/2012 15:27, Dominick Grift wrote:
>
>
> On Wed, 2012-08-08 at 09:11 -0400, Christopher J. PeBenito wrote:
>> On 08/07/12 14:55, Dominick Grift wrote:
>>> remove oidentd_read_user_content because interfaces aren' for internal
>>> usage
>>
>> That's not actually a refpolicy rule.
>>
>
> Am not going to spend time in the archives to find where this was
> touched or argue but you pointed this out once and it actually makes
> good sense. So whether it is a rule or not i will continue with this
> guideline.

May I have a word about it ?

A rule which strictly forbids using interfaces internally would not make 
any sense.

Interfaces are the abstraction of functions (or procedures) in classical 
procedural (imperative) programming.

Therefore, interfaces should always be preferred, when they improve 
readability and more importantly maintanability and (internal) modularity.

The above view also matches quite well with the advice that Christopher 
has given you, because if a very elementary interface is created for 
internal use (a good example is perhaps the initial mistake I've made 
while creating the mcelog module), then its cost overweights its 
benefits (both in terms of programming time/complexity and in terms of 
readability, because it would be split in different files).

So, in my opinion, this means there isn't a general and rigid rule that 
can be stated, but only good sense and a little of experience might help.

Regards,

Guido