Shibboleth Developers

[Nate Klingenstein <>]

> I think we have general agreement that the docs need to be broken up 
> into
> smaller bits and support multiple paths through them, so this is on the
> right track.  I'm kinda skeptical about this custom-build approach 
> though,
> since docs should be available both bundled with the package code and
> online from the web site.  Seems like a more traditional approach with 
> a
> table of contents and hyperlinked chapters would be at least as 
> effective
> and simpler to build.  Also, I think our direction should be to 
> separate
> Shib docs from InCommon docs; your approach seems to link them 
> together in
> the build process.

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.

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.  All the questions were 
thrown in only as mock-ups and would be, of course, open to debate.

As far as the difficulty in building this goes, it'd be very, very 
minimal.

I'd love to hear Walter's suggestions.

Thanks,
Nate.

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

   http://archives.internet2.edu/

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