A couple of thoughts. First of all the attribute release is a most welcome addition to the CAS protocol and I really look forward to use it.
I would think carefully about the road ahead, and as I see it there are three options: 1. "Accidentally" print multi-value attributes as a list of sorts which is currently done, and the Java client likewise "accidentally" supports and interpret as a list. 2. Explicitly not support multi-value attributes and either remove them or print the first item in the list only pretending that it is a single value. 3. Actually implement, in the server at least, as suggested in the specification. I'd recommend sticking to the specification in the protocol draft and use any of the last two options. I agree that multi-value attributes are common, indeed we have such that I would most definitely want to use and would prefer support as specified, but I could wait for another iteration. I think that the current RC2 server behavior is risky, since implementations may come to depend on a de facto undocumented behavior and blow up at a later upgrade which prints multi-value attributes some other way. The server interface is the XML output and not the Java client library. Regards, /Fredrik On tis, 2013-11-05 at 08:11 -0500, Marvin Addison wrote: > > I'm not saying that the 4.0 must support multi-valued attributes. > > I believe it would be a big mistake to fail to provide some reasonable > support for multi-valued attributes out of the box. Many if not most > directory attributes are naturally multivalued, notably role data used > for authorization; lack of support for that case would likely invite > the sorts of one-off customizations that we presumably want to > curtail. > > M > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
