Shibboleth Developers

["Scott Cantor" <>]

> Chad, before I consider any of your specific questions, would you (or
> someone else) comment on the overall design goals with respect to the
> Java SP?  For instance, you mentioned a couple times in passing that
> the Java SP should be compatible with the C++ SP.  If that is an
> explicit design goal, then any discussion re requirements and
> functionality is an academic exercise, is it not?

Why can't the C++ code change to match it?

> If functional compatibility with the C++ SP is a goal, then what
> subset of the overall functionality of the C++ SP will be implemented
> in Java SP 1.0?  Certainly it's not possible to duplicate the rich
> functionality of the mature C++ SP in such a short time frame.

We're not releasing incomplete code. When the Java version is done, 2.0 will
be released, and not before. But 75% or so of the SP is session caching and
web server API portability, and if we dodge some or all of that in Java, the
code is quite trivial.

> Speaking of overall design goals, a more layered, compartmentalized
> architecture would be desirable.  In other words, if the architecture
> were not so tightly bound to the browser profiles, the Java SP
> implementation might be brought to bear on other problems.

The code is already modular, extremely so in 1.3. The configuration is the
context and the context here is a web server. Take away the context and YOU
must provide your own. It can't just magically work.

The architecture of the SP as a whole can't be divorced from the browser
profiles, IMHO. They are entirely the point. I will repeat my earlier
analogy. Try using mod_auth_ldap as a generic LDAP query tool.

-- Scott