On Tue, Jun 24, 2014 at 04:05:08PM -0400, Simo Sorce wrote:
On Mon, 2014-06-23 at 09:55 +0200, Jakub Hrozek wrote:
> On Sun, Jun 22, 2014 at 09:34:54PM -0400, Simo Sorce wrote:
> > > I would prefer that, yes.
> >
> > I would prefer not.
> >
> > > I am hoping other SSSD developers would chime in as well so that the
> > > decision is not a one man party, but I personally prefer the code to
> > > read consistently. If the socket underneath is a shared NSS one or a
> > > NFS one is an implementation detail.
> >
> > But it has extremely important consequences on locking and thread
> > safety, and using aliases, while it may help readability in some areas
> > can also be quite confusing from the coherency POV.
> >
> > Simo.
>
> OK, what is your proposal?
To use only one function name to access a pipe. The function refers to
the communication channel used, not the commands sent on it.
If you prefer to rename the ..nss.. function to something more abstract,
that's fine too.
Simo.
Then I actually, agree, as I wrote previously:
I would expect either:
nss_lock()
do_stuff_with_nss()
nss_unlock()
or s/nss/nfs/
So I'm fine with using nss. I don't like renaming the function to something
generic, I would still prefer to see what pipe is used.