Shibboleth Developers

[Walter Hoehn <>]

So, there is a natural tension here between two desires:

	1) Keep the hurdles to re-factoring as low as possible, so the code 
can evolve most efficiently
	2) Keep existing users of the software happy by not pulling the rug 
out from under them

Both are good ends, obviously, but they are in some sense mutually 
exclusive.  It seems to me that a reasonable compromise is to divide 
things up logically into pieces that 1) can be changed at will  2) can 
be changed but needs to be discussed within the development group  3) 
cannot be changed without communicating with other constituents.

My opinion is that an internal API in shibboleth reaches the third 
category only when we have a discussion like the one we are having now 
where somebody says "hey, stability in this particular area is 
important to me".  So, we can try to work with folks in this regard, 
but they shouldn't be making assumptions without speaking up.

-Walter


On Apr 29, 2005, at 1:46 PM, Tom Scavo wrote:

> Perhaps, but an orderly, phased out obsolescence is preferable to an
> out-and-out modification of the API.  In other words, formally
> deprecate any legacy components for a predictable period of time
> preceding their disappearance.  This is especially important going
> forward since shib, gridshib, lionshare, etc. are developing
> more-or-less along separate paths.  We would like some guarantees (or
> at least some advanced warnings) with respect to API stability.

Attachment: smime.p7s
Description: S/MIME cryptographic signature