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

[Philipp von Weitershausen]

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.
> 
> 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.
> 
> In Java, most interfaces have some abstract class that buffers the user
> from changes to the interface. While that's certainly not what we want,
> it'd be nice to capture the spirit of that pattern. I don't know what
> this would look like in Zope 3 though.

It would look like Jim's suggestion above. We look up according to the 
old interface and then adapt to any new contract that we nowadays expect 
from the utility. Newer implementations will already provide the new 
contract, so that adaption returns the object identically. For old 
implementations, as in this case pluggableauth, we only have to write 
this one adapter (which wouldn't even have to live in the pluggableauth 
package, it could be unter some bbb module). That means no messing with 
old code and no evolution scripts.

I disagree with you on the pressure to get interfaces absolutely correct 
the first time. Nobody can foresee such refactorings. You design an 
interface and you write the implementation at the time. Then, over time, 
there'll be lots of code that will look up stuff according to that 
interface. We can hardly avoid that (and I don't think we want to).

If the evolution pattern is to change all places where this look up is 
taking place, then I think *that* is a lot of pressure. Every teeny 
interface refactoring will require a tremendous change of many different 
places in Zope, while the contract hasn't even changed. So why bother 
changing all the places that still only want the old contract? When 
refactoring, you know when you explicitly want the new contract anyway.

I think we should institutionalize this pattern as a public interface 
evolution pattern.

Philipp