[Zope3-dev] HEADS UP: PAU (pluggable authentication) users

[Garrett Smith]

Jim Fulton wrote:
> Garrett Smith wrote:
>> Jim Fulton wrote:
>> 
>>> Garrett Smith wrote:
>>> 
>>>> I wonder if it's really a problem if we never upgrade to
>>>> IAuthentication2 unless a particular API is needed. It might
>>>> actually be less confusing to not have '2' showing up everywhere.
>>>> Only people who care need to deal with it.
>>> 
>>> The problem is that code that wants IAuthentication2 will need to be
>>> careful.  If it asked for an IAuthentication utility and an
>>> IAuthentication2 utility, it might get a different answer.  There
>>> could, theoretically, be a closer IAuthentication.  Such code wold
>>> probably be better off doing something like:
>>> 
>>>   auth = component.getUtility(IAuthentication)
>>>   auth = IAuthentication2(auth)
>>> 
>>> at which point, we might as well have a ILogout interface that we
>>> adapt to.
>> 
>> 
>> This seems like a lot of pressure to get interfaces absolutely
>> correct before releasing them. There's no decent evolution scheme.
> 
> I don't agree.  In general, we are going to get things wrong the first
> time(s).  This is why we have a deprecation-based evolution process.
> If we had followed that process in this case, we would have:
> 
> - deprecated IAuthentication
> 
> - provided backward compatibility for 2 release cycles
> 
> We didn't follow this process in this case.  Authentication
> utilities that provided IAuthentication were broken.  Also, we
> didn't generate deprecation warnings when IAuthentication
> was used.
> 
> Evolution is intrinsicly hard.  It is also necessary.

I'm certainly not debating this. My point is that this is a test case
for interface evolution and that we should have an approach that's not
burdensome, ELSE there will be pressure to get interfaces right the
first time.

> In *this* case, it's not obvious to me that we actually want
> to evolve IAuthentication.  I'm not certain that the logout
> capability is intrinsic to authentication.  That's why I'm OK
> with an adapter-based approach.

I don't have a strong opinion, though it feels to me that logout belongs
in IAuthentication. I'm also uneasy about seeing the landscape become
littered with adaptation.

>> It would be nice to just modify IAuthentication and then deal with
>> broken implementations in some elegant way. We'd be saying, "the
>> contract's changed, but we'll let you get away with the breakage for
>> two release cycles" which is really what's going on.
> 
> I guess this is an option.  This is what Stephan wanted to do.
> 
> In the past, I've always been opposed to modifying interface, as that
> seemed unfair in some way, but, at least in some cases, it might
> be preferable to dealing with interface revisions.
> 
> (This would be a useful discussion to have on interface-dev.)

In the interest of doing the least-disruptive-thing (bearing in mind the
need to get 3.1 out), I think we should use an adapter approach and give
interface evolution the vetting it deserves. It's an important issue,
but IMO this isn't the best time/place to tackle it.

Sound about right?

 -- Garrett