Password sync plugin, and questions about plugin criticality

[Sam Hartman]

>>>>> "Roland" == Roland Dowdeswell <elric at imrryr.org> writes:

    Roland> On 1151337186 seconds since the Beginning of the UNIX
    Roland> epoch
    Roland> Ken Hornstein wrote:
    >>

    >>> We have all seen the ... fun of library versioning problems,
    >>> 32/64 bit lib issues, etc. that are caused when you decide to
    >>> go with a plugin architecture rather than an IPC architecture.
    >>> Is there a compelling reason in this case to not avoid these
    >>> issues?

    >> There's already a plugin architecture in MIT Kerberos for
    >> extensions.  This was the direction they decided to go in; I'm
    >> just along for the ride :-) (Although I see no reason why you
    >> couldn't create a simple "shim" plugin that talked via IPC to
    >> the complicated bits).

    Roland> I'm not specifically complaining about your actions but
    Roland> rather the choice to go with a plugin system to start
    Roland> with.  It encourages the wrong thing.

In principle I have no problem with this approach.  Long term I'd love
to get there.  However this involves focusing a lot more work into
clearly defined abstractions and to network data representations.  At
this moment in time, MIT does not have the resources to do as much
with an IPC mechanism as a plugin mechanism.

--Sam