Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Fri, 2 May 2003, Nate Klingenstein wrote:

> In the last e-mail, I mentioned this table-of-contents structure with
> hyperlinked chapters.  The thing is, it would be very simple to build
> the table of contents according to what you need, leaving the user with
> a greatly reduced version of the deploy guide, if that's sufficient.

This kind of selective narrowing makes sense for, say, deciding which
binary version of an app to download, but I just don't buy it for
documentation.  I'd click the "give me the whole doc" option, then poke
around in it once I got it.  Maybe I don't know which web server I'm going
to use, and I want to see the instructions for each as part of choosing.
It also seems to me to complicate support.  "Didn't you read section 3
where we say to do X?", uh, well for you it's section 4.  Maybe I'm
missing something but I don't see that hiding content does people any
favors.

> As far as decoupling InCommon from the deployment process, that clearly
> introduces a second layer of configuration for adopters, but this may
> be an important political layer of abstraction.

Umm, hmm?  Shibboleth is a general piece of software, we already know
folks are using it outside of InCommon and outside of the whole federation
notion in general (in fact our longest-running deployment does this).  It
needs docs that describe it.  InCommon is just one way of using it.  They
are really and truly separate.  I think being clear on the separation will
help adopters, not hinder them.

 - RL "Bob"


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--